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

[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

[kika.livejournal.com]

Это не "можно превратить в сопли", а это является соплями. А героическим трудом и талантом это можно превратить в что-то читаемое и сопровождабельное. Таланту можно придумать лучшее применение, ятакдумаю.

А тот сниппет, который ты привел, просто написан плохим программистом. Который не любит писать на С, а его заставили. Я понимаю что ты так не пишешь, это ты просто утрируешь для иллюстрации. Но не понимаю зачем приводить иллюстрации из жизни идиотов, они все равно не заморачиваются этими вопросами.

У меня есть для тебя не имитатор идиота, а совершенно настоящий код из реального проекта.

switch(error)
{
case ERR_XXXX:
throw 1;
case ERR_YYYY:
throw 2;
case ERR_ZZZ:
throw 3;
...etc...
}

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

А теперь скажи мне, любимец богов, в на пять вызовов вверх, туда, где я все возможные ошибки write буду ловить
как ты будешь отличать ошибку одного write от другого? В коммуникационных протоколах, в частности, это бывает очень важно.

[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]

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