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

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

Вынимай.

Я считаю что исключения могут бросать фреймворки, которые не просто дают какой-то набор функциональности, а диктуют и архитектуру и дизайн и структуру программы в значительной степени. Например 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]

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