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

[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

[tobotras]

Ну, одно из двух. Или трех.

[avnik.livejournal.com]

У таких заек вообще всегда может константа OK возвращатсья -- не зависимо от того что произошло на самом деле.

PS А про исключения их не учили?

[kika.livejournal.com]

А про исключения их не учили?

Учили, довольно сдержанно впрочем, что я одобряю.
Вообще говоря, библиотечные функции, которые выкидывают из библиотеки наружу исключения, должны приводить не только к кастрации авторов, но и к декапитации.

[krotoff.livejournal.com]

Кастрируй меня как Джордано Бруно первым.
Должны библиотеки бросать исключения. Просто обязаны.
"Бросай ниже, лови выше!"

Стандартная библиотека бросается исключениями налево и направо.

А вот за метание недокументированных исключений - готов тебе помочь в кастрации.

[kika.livejournal.com]

Вынимай.

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

try
{
govno(); // which throws()
}
catch(...)
{
return -1;
}

называется в обиходе "развешивать сопли".

Стандартную библиотеку, как и буст, как и последние плюсы дизайнили козлы, которых надо кастрировать первыми. Так что не аргумент.

[alexott.livejournal.com]

а сколько интересных багов можно получить кидая exceptions из динамически подгруженной библиотеки...
у нас был баг, когда подгружаемый модуль был слинкован статически с libstdc++ немного другой версии, и он бросал исключения - вся конструкция просто грохалась - исключение не ловилось

[kika.livejournal.com]

Справедливости ради, это относится практически к любой stateful функции рантайма, например к аллокатору. Языки, носящие с собой всю машину, типа явы или большинства ФП, этой проблемы лишены просто по причине отсутствия причин для возниконовения.
Но с аллокатором проблема решается реализацией своего, или применением готового, обученного бороться с проблемой, а что делать с исключениями? Поэтому-то они должны быть исключены :-) из обычаев делового оборота, особенно разработчиками библиотек, ибо их невозможно "реализовать". Они там, где-то, в глубине сибирских руд. И если с ними проблема, то эта жопа решения не имеет, кроме замены библиотеки.

Возможны частные случаи, типа обладания сакральным знанием что надо имплементировать в своей программе из __crt_hui_znaet_chto() для мелкософта v9.0 чтобы получить результат. Но я б таких не просто кастрировал, а еще бы и семьи вырезал, для гарантии.

[alexott.livejournal.com]

насчет последнего тезиса - полностью согласен...

[krotoff.livejournal.com]

Это можно превратить в сопли, даже легко. Но это будет типичный abuse.
А можно не превращать, что есть нормальный use.

Те же коммуникационные части: очень показательный пример.
При "правильном" писательстве на Си код быстро превращается в кучу соплей навроде:
int my_write(....) {

if (write(h, buf, n) != n) {
ap->my_errno = errno;
return -1;
}
...
if (write(h, smth, m) != m) {
ap=>my_errno = errno;
return -1;
}
...
}

Хуже того, каждый вызов my_write нужно будет тоже огораживать таким забором. И каждый вызов вызывающего нужно огораживать, и так до самого верха коммуникационной части. И это неизбежно, при наличии желания писать "правильно" (просто другого способа писать "правильно" не предусмотрено.

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

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

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

[kika.livejournal.com]

Как ты предлагаешь документировать исключения?

[xfyre.livejournal.com]

я так понимаю что Java не очень корректный пример, т.к. это именно фреймворк.

интуитивно я скорее согласен, что если речь идет про плюсовую библиотеку - вся обработка исключений долна быть внутри, т.к. методологий работы на плюсах существует великое множество и совершенно не факт, что разработчикам конечного продукта их собственные coding guidelines позволяют механизмы исключений использовать.

но в этом случае тезис про кастрацию должен иметь понятную оговорку "... для библиотек на C/C++".

[kika.livejournal.com]

Это некорректный пример для ответа на предыдущий (вернее, эээ, sibling) камент, а на этот - корректный. Потому что если использовать исключения, то они должны быть документированы как в яве.

[krotoff.livejournal.com]

Знаю только один нормальный способ: письменно в документации :)
В комментариях - ну разве что в самых простецких случаях.

А вот списки исключений и то, во что в С++ превратилось в unexpected - считаю костылищем ужасным. Либо давайте семантику, навроде статической проверки throws в Java, либо вообще не делали бы.

[kika.livejournal.com]

Я тебе хуже скажу - комментарии в программе сами по себе являются соплями. И документация, которая описывает исключения - соплями в квадрате. Вернее, она может их описывать, для знакомства с объектом без взятия его в руки, пожалста, но никак не как оперативное средство работы. Ты ваще соображаешь что ты говоришь - я использую какую-то инфраструктуру из нескольких десятков классов, которые внутри себя там что-то тоже используют, и я должен прочитать документацию по всем этим десяткам чтобы построить "правильный" catch на верхнем уровне? Это не программирование, это махание кайлом на рудниках.

Я это уже писал тут и могу проитерировать - программа есть форма кремниевой жизни. И она живет и развивается. А комментарии и документация - это заметки биолога и Ветхий Завет. Интересно пачетать!

[krotoff.livejournal.com]

Насчет комментариев - согласен.

А вот насчет документирования исключений - совсем наоборот. Разделы документации, в которых говорится об обработке ошибок, если они есть :D - они же самые увлекательные разделы во всей документации.
Что функция/класс делает - это и так понятно, в большинстве случаев даже понятно как они это делают, тут главное понять подходят они тебе, или нет. Ну и понять как их предлагают использовать, не креативным образом, а по назначению.

А вот обработка ошибок - это всегда интересно и увлекательно. И, главное, разнообразно. Почти как развязки в детективах :D про смерть и про любовь.
Если ее (обработку ошибок), конечно, документируют. Что, к сожалению, не всегда делают.
У тебя же вон там, в начале топика, очень правильный пример на эту тему есть.

Ты же не предлагаешь писать, не читая документацию, что то же метод, конечно, но тут уже не вижу разницы, не читать документацию по поводу return values, или по поводу исключений. Хотя согласен, что всякие return codes в нефатальных случаях игнорировать проще.

[kika.livejournal.com]

Проблема с комментариями и документацией не в том что их (не) читает программист, а в том, что их не читает компилятор. Все что не читает компилятор - это потенциальная сопля. Которая неизбежно превратится в кинетическую.

[krotoff.livejournal.com]

+1.