Загадки для программистов

[kika]

Мы ребята деловые, ищем щели половые.


// false return value indicates an error
virtual bool initialize();


Следующий метод:

// non-zero return value indicates an error
virtual bool move();


Теперь внимание, вопрос:

// write storage dependent fast resume entries
bool write(entry& rd);


Comments

[krotoff.livejournal.com]

> Я не помню деталей, но смысл передал верно. Меня читают как минимум два человека, охуевавших от этого кода вместе со мной, есличо - поправят.

Записывай меня третьим (четвертым). За такое - кастрировть! четырехкратно.

> отличать ошибку одного write от другого?
В том и прикол, что если нужно ошибку одного write отличить от ошибки другого - остается только жевать сопли. Тут исключения - зло страшенное, ужасное, abuse, с потенциальной кастрацией.

Хороши эти самые исключения там, где райтов много, и отличать их не нужно. Например транзакция, со многими операциями, где реакция на ошибку write (за исключением одного очень специального случая) одна: обломись бабка, на сервер твой уронили утюг, соединения больше нет. И уже абсолютно не важно на какой именно стадии она отвалилась. Последствий ее уже никто не увидит.

Например SQLException в JDBC поперек SQL_SUCCESS в ODBC. Первые сами по себе ничем не лучше вторых, но позволяют писать проще и прямолинейнее.

[kika.livejournal.com]

Хороши эти самые исключения там, где райтов много, и отличать их не нужно.

То есть получается что мы используем и то и другое вперемешку. А не будет ли такой дизайн достоин кастрации? Для соблюдения правила суммирования наказаний придется резать по частям.

[krotoff.livejournal.com]

Режь по частям.
Да, приходится вперемешку. Те же new и new(nothrow).

Вопрос лишь в пропорциях. Если 99% вписывается в один патерн, а 1% требует соплей (nothrow), то считаю, что все сделано правильно.

Если write (тот, который man 2 write) вместо -1 и errno выдавал бы мне исключение, то я бы ему только спасибо сказал. Потому как он, как и new, мне более нужен в таком виде.

[kika.livejournal.com]

Жулик. 1% при 99% - это статистическая погрешность. А если 60 на 40?

"мне нужен". А разработчики библиотек пишут их не для тебя или меня, а для всех. И чем сильнее библиотека форсирует паттерн тем меньше ее используют. Я лично соскочу с данной как только появится альтернатива (или ресурсы на переписывание функционала).

[krotoff.livejournal.com]

Ну дык, еще дедушко Фрейд заметил, что если речь заходи о кастрации, то все начинают со страшной силой жульничать.

Если 60/40 то жопа почти в чистом виде. И одну из альтернатив нужно обрабатывать напильником. Делать write_throw и write_nothrow.

Что до разработчиков библиотек, то мне приходится, очевидным образом libc использовать, а у нее патерн известный. Но для доброй половины функций он мне менее симпатичен, чем паттерн ACE. (Хотя ACE тоже использовать не могу, но уже не по техническим причинам, поэтому приходится его частично повторять.)

[krotoff.livejournal.com]

UPD: Кстати, очень разумные слова по поводу исключений написали Керниган и Пайк (их, вроде, в особой любви к с++ не заподозришь) в "Практике программирования". Там по поводу собственно исключений буквально пара страниц, я вчера отыскал. Раздел 4.7, кажется.

Один из их советов: "обнаруживай ошибки на возможно низком уровне, обрабатывай на возможно высоком" (не дословно). Он как раз "в струе" с исключениями.

[kika.livejournal.com]

Осталось теперь определить "обрабатывай" и "обнаруживай". Я, собственно, не спорю что всплывающий из коммуникационной библиотеки мессаджбокс это похуже чем исключение :-)