Здравствуйте, Erop, Вы писали:

E>Не правда ваша.
E>1) обычный assert приводит к тому, что программа делает красиво ручкой, а хотелось бы ещё и документик сохранить, например

assert не предназначен для продуктивного использования.

E>2) assert, который провалился у пользователя, ситуация неприятная, но, увы, возможная. Дальше всё упирается в простой вопрос кто за что готов платить Если речь идёт о простом таком пользователе-человеке, то ему хорошо бы получить как-то просто после этого инструкции как решить его проблему. А разработчику хорошо бы как-то получить описание возникшей у пользователя ситуации, приведшей к проявлению ошибки...

assert не должен появняться у пользователя.

Здравствуйте, minorlogic, Вы писали:

M>пример ошибки выполнения.
M>bool fileExist(...);

M>Во время выполнения сетевой ресурс на который ссылается путь был отключен, это ошибка выполнения fileExist, и вполнен нормально в таком случае кинуть исключение.

ИМХО, неудачный пример. Если ресурс был отключен (или не существовал), следовательно, file is not exist, следовательно, false? Кто-то выше уже сказал, что надо исходить из потребностей клиентского кода. Если клиентскому коду все равно, отключен ресурс или файла нет в природе, а ему нужно просто знать, может он или не может работать с этим файлом, то исключения будут только мешать. Хотя и тут тоже не без тонкостей: файл может существовать, но прав доступа у нас может и не быть...

Здравствуйте, slava_phirsov, Вы писали:

_>ИМХО, неудачный пример. Если ресурс был отключен (или не существовал), следовательно, file is not exist, следовательно, false? Кто-то выше уже сказал, что надо исходить из потребностей клиентского кода. Если клиентскому коду все равно, отключен ресурс или файла нет в природе, а ему нужно просто знать, может он или не может работать с этим файлом, то исключения будут только мешать. Хотя и тут тоже не без тонкостей: файл может существовать, но прав доступа у нас может и не быть...

Придумайте пример лучше, мне кажется идею вы уловили.

Здравствуйте, minorlogic, Вы писали:

M>Придумайте пример лучше, мне кажется идею вы уловили.

Лично мне не хватает исключений в арифметике (напр, тот же самый atan2(0, 0), или переполнение, или underflow). Вот крутится вычислительный алгоритм (например, решение системы нелинейных дифуров, описывающих работу электронной схемы), в котором в определенной ситуации, при некоторых исходных данных, может возникнуть какая-либо из перечисленных проблем. ИМХО, если бы он сразу прервал вычисления, честно сказав "ну ни х.. себе", как та японская лазерная пила из анекдота, это было бы лучше проверок errno. Хотя, может я уже окончательно отстал от жизни, и в новом стандарте

asin(-2)

или

char x = 0xFF;
x *= 2;

кидают исключения?

Здравствуйте, minorlogic, Вы писали:

M>assert не предназначен для продуктивного использования.
поэтому приходится иметь свой аналог, так как поведение стандартного assert не настраиваемо...

M>assert не должен появняться у пользователя.
Это всего лишь благое пожелание...

Здравствуйте, minorlogic, Вы писали:

M>Здравствуйте, Юрий Жмеренецкий, Вы писали:

ЮЖ>>Везде при подобном коде:

ЮЖ>>

/// \pre x > 10, p != NULL
ЮЖ>>void f(int x, int* p)
ЮЖ>>{
ЮЖ>>  assert(x > 10);
ЮЖ>>  assert(p);

ЮЖ>>  if(x > 10)
ЮЖ>>   throw std::invalid_argument("f::x"); // В клинических случаях добавляется запись в лог, etc.
ЮЖ>>                                        // Тип исключения в принципе не так важен, но это по  
ЮЖ>>                                        // сути логическая ошибка (std::logic_error).
ЮЖ>>                                        // Иногда можно увидеть std::runtime_error - но это уже похоже на саботаж

ЮЖ>>  if(!p)
ЮЖ>>   throw std::invalid_argument("f::p");

ЮЖ>>  //...
ЮЖ>>}

M>Кажется я начинаю понимать, у вас другая терминология.

Вряд-ли. Я показал пример недопустимого ни под каким предлогом для меня кода, но встречающегося на каждом шагу. Там из контекста обсуждения должно (как я надеялся) быть понятно что преобразование assert'a в исключение — абсолютное непонимание происходящего.

M>Вы пытаетесь проверить DBC входных и т.п. аргументов. Для этих целей лучше написать нормальный обработчик типа CHECK_DC(...); CHECK_PRE_DC(...); CHECK_POST_DC(...); и так далее.

Я понимаю о чем речь. Только в этом коде моего — только то, что я его показал.

M>Культура же програмирования на С++ подразумевает использования макроса ASSERT (assert) для проверки корректности програмым. Т.е. это проверка которая должна срабатывать ВСЕГДА.

Я знаю это и полностью согласен.

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, Юрий Жмеренецкий, Вы писали:

ЮЖ>>Иначе, при таком подходе (очень плохом, имхо), нельзя обнаружить все ошибки (логические).

E>Вообще-то нормальные программы ещё что-то и делают, так что ошибки в них можно найти и по результатам их деятельности

До обсуждения предусловий мы с Николаем еще не дошли...

ЮЖ>>Это другой вопрос (решаемый в принципе). Разница между возбуждением исключения и abort в этом случае — нет гарантий, что размотка стека не приведет к инициации других ошибок, нет гарантий что все данные останутся в порядке, нет гарантий что обработчик исключений не содержит багов, и т.д. abort выводит программу из состояния 'баг' с минимальными последствиями. Если же требуется все-таки не падать даже при наличии багов — то все эти проблемы придется все-таки решить.

E>Не правда ваша.
E>1) обычный assert приводит к тому, что программа делает красиво ручкой, а хотелось бы ещё и документик сохранить, например

Не обязательно.

E>2) assert, который провалился у пользователя, ситуация неприятная, но, увы, возможная.

Только если у него Debug версия


E>4) Я не знаю ситуаций, когда обработка ошибки совсем не важна. Если уж прога упала, то кто-то что-то должен написать заранее такое, чтобы жизнь продолжилась.

Программа может упасть из-за многих причин, которые не зависят от программиста. Здесь обсуждались только логические ошибки.


ЮЖ>>Но здесь возникает забавное логичское противоречие — если программист может решить эти проблемы не наплодив новых багов — почему он не может их не плодить изначально?

E>Потому, что при разработке системы обработки ошибок, её обычно проектируют и тестируют.

А для всего остального это необязательные шаги?


E>Кроме того, во многих случаях пред/пост-условие трудно не то, что бы проверить, но даже хотя бы и выписать формально...

Если не далать ляпов, то все они проверяемы — иначе теряется смысл. (Делать для функции выделения памяти предусловием существование блока необходимого размера(или более) в большинстве случаев — абсурд). Вот где есть проблема — так это в неполной идентификации постусловий.

E>Если assert кидается исключениями

Без хаков такого не бывает.

Здравствуйте, Юрий Жмеренецкий, Вы писали:

ЮЖ>Здравствуйте, minorlogic, Вы писали:

M>>Здравствуйте, Юрий Жмеренецкий, Вы писали:

M>>Культура же програмирования на С++ подразумевает использования макроса ASSERT (assert) для проверки корректности програмым. Т.е. это проверка которая должна срабатывать ВСЕГДА.

ЮЖ>Я знаю это и полностью согласен.

Прошу прощения , я не уследил за контекстом разговора.

Здравствуйте, crable, Вы писали:

C>>>И в третьих, ты сам описал ситуацию, при которой эти ассерты только мешают,
V>>Они не мешали, они стали мешать из-за бросания исключений оттуда, откуда можно было вернуть код возврата.
C>Можешь пояснить? Почему они стали мешать из-за бросания исключений и не мешали бы при использовании кодов возврата? Небольшой пример тоже не помешал бы.
Конструстор некоторого объекта, к примеру, арки по 3м точкам. Если три точки лежат, на одной прямой — то нужен код возврата который скажет, что центр арки найти невозможно. Пользователи библиотеки начинают пользовать конструктор прям в выражениях ничего не проверяя — работает до поры до времени.

C>>>более того, я, например, склонен считать, что так будет в большинстве случаев. Добалять ассерты только потому, что кому-то трудно раз в сто лет заставить студию перехватывать исключения выглядит, по меньшей мере нелепо.
V>>Во первых, в достаточно сложном приложении, включать по-умолчанию ловлю ассертов вообще не преемлемо, т.к. ассерты начинают летать в приложении с самого его запуска и вы постоянно будете на них натыкаться в отладчике.
C>Может быть не "ассертов", а "исключений"?
Очепатался

V>>Во-вторых, когда приложение "грохается" на исключении, чтобы воспроизвести падение, надо как минимум привести приложение в то состояние, в котором оно было перед самым падением, а это иногда оччень не просто, из-за количества действий которое нужно сделать и раннее включение ловли исключений этому будет только мешать.
C>Что, в данном контесте, значит "грохается"? Выбрасывает исключение, которое нигде не обрабатывается?
Я ниже написал про это:
C>>>Кстати, для того, чтобы поставить эту галку вовсе необязятельно перезапускать приложение.
V>>А исключение уже проскочило и не было поймано, поэтому придётся.

Здравствуйте, Юрий Жмеренецкий, Вы писали:

V>>Во первых, в достаточно сложном приложении, включать по-умолчанию ловлю ассертов вообще не преемлемо, т.к. ассерты начинают летать в приложении с самого его запуска и вы постоянно будете на них натыкаться в отладчике.
ЮЖ>-1
Там речь про исключения была
V>>Поэтому, ассерт вставляют перед исключением, чтобы "поймать падение" с первого раза и не мучится с перезапуском приложения и приведением его в состояние перед падением.
ЮЖ>Ммм... breakpoint в конструкторе исключения?
Тоже самое, что включить тип исключения в его ловлю "по-умолчанию".

Здравствуйте, jazzer, Вы писали:

J>Главная проблема с возвращаемыми значениями — это то, что они игнорируются по умолчанию (в отличие от исключений).

Да, в подавляющем большинстве кода, использующего возвращаемые значения, это огромная проблема. И усугубляется это тем, что подобного рода баги при нормальной работе программы не проявляются, а только когда происходит какая-нибудь очень редкая ситуация. На моей практике был прямо смехотворный случай, где из-за одной единственной пропущенной проверки embedded device входил в такое состояние, из которого его можно было вывести только с помощью hard reset-а с потерей всех данных.

Но в принципе, с возвращаемыми кодами ошибок можно сделать так, что если нет проверки, то вываливается assert (или сразу core dump). Alexandrescu описал один из вариантов реализации этой идеи в CUJ: http://www.ddj.com/cpp/184401917.

Ещё одна проблема с возвращаемыми кодами ошибок — это то, что они не позволяют возвращать нормальный результат работы функции через return. Приходится вводить out parameters, которые страдают своими проблемами. Я в своем проекте, где категорически нельзя было использовать исключения, даже написал такой класс, который совмещал код ошибки с результатом функции, result<T> (наподобие boost::optional<T>), чтобы можно было хоть как-то нормально возвращать результат.

Здравствуйте, Юрий Жмеренецкий, Вы писали:

ЮЖ>Я: вот такую конструкцию:

ЮЖ>

result r = api::f1(...);
ЮЖ>if(r == error_code1)
ЮЖ>  throw exception(...);

ЮЖ>легко можно преобразовать в такую:

ЮЖ>

checked_result r(error_code1);  
ЮЖ>r = api::f1();

А ещё лучше вот в такую:

api::f1() || die("f1() failed");

Hello, Perl!