Привет!

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

Итак, если кратко: эксепшины имеют право на существование, но их применение следует ограничить исключительно исключительными ситуациями.
Примеры. Эксепшин на невозможность выделения памяти — это правильно. Ситуация однозначно исключительная (во всяком случае для 99% прог и для 99% кода оставшегося 1% прог) и свидетельствует о том, что все действительно очень плохо. Эксепшин на невозможность открытия файла, преобразовать строку в число и т.п. для библиотечных классов/функций — это неправильно. Потому как это заставляет программиста, использующего эти библиотечные функции явно ловить эксепшины даже тогда, когда код возврата ему абсолютно неинтересен.

Теперь подробнее, почему это так:
1) Синтаксис С++ в случае ловли эксепшинов заставляет городить:

value=default_value;
try
{
    value=f();
}
catch(exception)
{
}

вместо

value=default_value;
    f(&value);

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

2) Компилятор С++ позволяет оставлять эксепшины без внимания:

void f()
{
    start_transaction();
    doit() ? commit_transaction() : rollback_transaction();
}

Программист, который пишет функцию doit() на очередной итерации разработки решил использовать в своей функции библиотечную функцию, кидающую эксепшин. Компилятор бессилен предупредить программиста, пишушего функцию f() о том, что некие действия могут быть вообще невыполнены, незавасимо от результата вызова doit().
Т.о. появляется фактор "неожиданности", который мне лично очень претит и который у меня ассоциируется с оператором goto

3) Отладка. Понять откуда и из-за чего пришел эксепшин в проге напичканной эксепшинами (без приема особых мер) бывает довольно затруднительно. А приходит он как раз из тех участков проги, в которых его никто не ожидает. В случае же непроверки кода возврата — прога просто вылетит на ближайшем assert'e.

4) Эффективность. С++ относится к тем языкам, используя которые, под эффективносью, в числе прочего, понимают и быстродействие и размер кода. Если на быстродействие эксепшины, как правило, и не сильно вляют, то код раздувают весьма эффективно.

5) Конструкторы/деструкторы. Распространяться не буду, уверен все и так поняли про что я. Опять упираемся в язык С++ как таковой. Т.е. все это заставить работать можно, но только зачем...

Все вышеперечисленные тезисы заставляют меня воздерживаться от применения механизма эксепшинов при разработке на С++. Поэтому просто приведу пару примеров тех редких случаев, когда я посчитал использование эксепшинов оправданным и использовал этот механизм.
1) Коммуникационный протокол связи по COM-порту. Эксепшины на ошибку COM-порта и "глобальный" таймаут приема/передачи. В обоих случаях дальнейшее продолжение связи бессмысленно и очень удобно кинуть эксепшин из "недр" и поймать его на самом "верху", нежели возиться с кучей кодов возврата.
2) Клиент, тупо вызывающий методы сервера. При любой ошибке вызова (не путать с результатом вызова) кидается эксепшин, который отлавливается и расшифровывается "наверху" в основном цикле приложения. При этом от клиента не требуется какой-либо особой реакци на эти ошибки (разве что показать юзеру). Т.е. юзер просто инициирует некое действие — клиент "переводит" его на сервер.

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

V>Начинаю обещанный топик Сознательно начинаю его именно в форуме по С++, т.к. хочу ограничить обсуждение именно этим языком (применительно к другим языкам, например к джаве, мое отношение к сабжу отличается с точности почти до наоборот

[skipped]

Добавлю еще одно неудобство — крайне трудно правильно обработать exception, если, конечно, это не глобальный сбой и ничего кроме "Ошибка, работать нельзя" ((с) некий Никитинский) сделать невозможно. Проверено на горьком опыте. Либо приходится обрабатывать их почти там же, где они генерируются (что вообще ставит под сомнение целесообразность их применения), либо на более верхнем уровне невозможно учесть условия/среду их возникновения, и, соответственно, правильно выкрутиться из ситуации.

V>Все вышеперечисленные тезисы заставляют меня воздерживаться от применения механизма эксепшинов при разработке на С++. Поэтому просто приведу пару примеров тех редких случаев, когда я посчитал использование эксепшинов оправданным и использовал этот механизм.
V>1) Коммуникационный протокол связи по COM-порту. Эксепшины на ошибку COM-порта и "глобальный" таймаут приема/передачи. В обоих случаях дальнейшее продолжение связи бессмысленно и очень удобно кинуть эксепшин из "недр" и поймать его на самом "верху", нежели возиться с кучей кодов возврата.
V>2) Клиент, тупо вызывающий методы сервера. При любой ошибке вызова (не путать с результатом вызова) кидается эксепшин, который отлавливается и расшифровывается "наверху" в основном цикле приложения. При этом от клиента не требуется какой-либо особой реакци на эти ошибки (разве что показать юзеру). Т.е. юзер просто инициирует некое действие — клиент "переводит" его на сервер.

Обобщим — exception'ы целесообразно применять, когда их обработка не имеет смысла...

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

V>Привет!

V>Начинаю обещанный топик Сознательно начинаю его именно в форуме по С++, т.к. хочу ограничить обсуждение именно этим языком (применительно к другим языкам, например к джаве, мое отношение к сабжу отличается с точности почти до наоборот

Вообще я уже начал подобный (он щас в "философии")

V>Итак, если кратко: эксепшины имеют право на существование, но их применение следует ограничить исключительно исключительными ситуациями.
ИМХО именно для этого они и преднезначены.
V>Примеры. Эксепшин на невозможность выделения памяти — это правильно. Ситуация однозначно исключительная (во всяком случае для 99% прог и для 99% кода оставшегося 1% прог) и свидетельствует о том, что все действительно очень плохо.
Да уж
V>Эксепшин на невозможность открытия файла, преобразовать строку в число и т.п. для библиотечных классов/функций — это неправильно. Потому как это заставляет программиста, использующего эти библиотечные функции явно ловить эксепшины даже тогда, когда код возврата ему абсолютно неинтересен.
Не согласен. На мой взгляд разработчик библиотеки лучше знает, когда нужно, а когда не нужно обращать внимание на результат работы некоторой функции. В случае с исключением игнорировать его сложнее, чем код возврата.

V>Теперь подробнее, почему это так:
V>1) Синтаксис С++ в случае ловли эксепшинов заставляет городить:
V>

V>value=default_value;
V>try
V>{
V>    value=f();
V>}
V>catch(exception)
V>{
V>}
V>

V>вместо
V>

V>value=default_value;
V>    f(&value);
V>

А если нельзя по value определить — корректно отработала f или нет:?! В общем случай с atoi в чистом виде. Я согласен, что есть ситуации, когда на ошибку преобразования можно забить, и довольствоваться тем нулем, который она вернула. А если нет?! Не так давно я убил день на поиск именно такой ошибки!
V>В более практических случаях это здорово поганит читабельность. Кроме того, работает принцип: "на любом языке пишут так, как короче".

Ну, испоганить код можно всегда, и не только try-catch. Если же эти блоки натыканы на каждом шагу, то это по крайней мере наводит на подозрения...

V>2) Компилятор С++ позволяет оставлять эксепшины без внимания:

V>

V>void f()
V>{
V>    start_transaction();
V>    doit() ? commit_transaction() : rollback_transaction();
V>}
V>

V>Программист, который пишет функцию doit() на очередной итерации разработки решил использовать в своей функции библиотечную функцию, кидающую эксепшин. Компилятор бессилен предупредить программиста, пишушего функцию f() о том, что некие действия могут быть вообще невыполнены, незавасимо от результата вызова doit().
V>Т.о. появляется фактор "неожиданности", который мне лично очень претит и который у меня ассоциируется с оператором goto

Да, это не есть гут. Остается только внимательнее изучать документацию на библиотеку.

V>3) Отладка. Понять откуда и из-за чего пришел эксепшин в проге напичканной эксепшинами (без приема особых мер) бывает довольно затруднительно.
Повторюсь: "напичканная исключениями" программа наводит на подозрения. ИМХО сам термин "исключительная ситуация" указывает на то, что такие ситуации — нечто редкое...

V>А приходит он как раз из тех участков проги, в которых его никто не ожидает. В случае же непроверки кода возврата — прога просто вылетит на ближайшем assert'e.
При наличии этого assert'а (несколькими строчками выше кто говорил о возможности игнорирования кодов возврата... )

V>4) Эффективность. С++ относится к тем языкам, используя которые, под эффективносью, в числе прочего, понимают и быстродействие и размер кода. Если на быстродействие эксепшины, как правило, и не сильно вляют, то код раздувают весьма эффективно.

Да, к сожалению так

V>5) Конструкторы/деструкторы. Распространяться не буду, уверен все и так поняли про что я. Опять упираемся в язык С++ как таковой. Т.е. все это заставить работать можно, но только зачем...

Просто осторожнее надо быть в подобных местах.

Все вышеперечисленные тезисы заставляют меня воздерживаться от применения механизма эксепшинов при разработке на С++.
А меня нет.
V>Поэтому просто приведу пару примеров тех редких случаев, когда я посчитал использование эксепшинов оправданным и использовал этот механизм.
V>1) Коммуникационный протокол связи по COM-порту. Эксепшины на ошибку COM-порта и "глобальный" таймаут приема/передачи. В обоих случаях дальнейшее продолжение связи бессмысленно и очень удобно кинуть эксепшин из "недр" и поймать его на самом "верху", нежели возиться с кучей кодов возврата.

А что, такая ситуация (невозможность дальнейшей работы) возможно только при работе с портом?!
Я уже устал это повторять, но скажу еще раз: исключения — для исключительных ситуаций (т.е. для таких, после возникновения которых бессмысленно продолжать работу). Если же есть код типа:

пробуем что-то сделать
получилось - хорошо, едем дальше
не получилось (поймали исключение) - не беда, что-то подправляем и едем дальше

то явно речь не идет о какой-то исключительной ситуации, а просто о варианте поведения. Использовать здесь исключения по крайней мере неэффективно.

V>2) Клиент, тупо вызывающий методы сервера. При любой ошибке вызова (не путать с результатом вызова) кидается эксепшин, который отлавливается и расшифровывается "наверху" в основном цикле приложения. При этом от клиента не требуется какой-либо особой реакци на эти ошибки (разве что показать юзеру). Т.е. юзер просто инициирует некое действие — клиент "переводит" его на сервер.

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

V>Начинаю обещанный топик Сознательно начинаю его именно в форуме по С++, т.к. хочу ограничить обсуждение именно этим языком (применительно к другим языкам, например к джаве, мое отношение к сабжу отличается с точности почти до наоборот

В доконку хотел бы подкинуть пост из недр "знаменитого" топика "Выйти из двух циклов сразу" http://www.rsdn.ru/forum/Message.aspx?mid=61162&only=1

Автор: m.a.g.
Дата: 06.06.02

Как насчет данного случая? В плане применябельности эксепшенов.

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

B>Вообще я уже начал подобный (он щас в "философии")
В философии это будут общие слова ни о чем Типа: "и то и то имеет смысл в зависимости от ситуации" и с этим трудно не согласится. Я же говорю, очень много чего зависит от средства разработки.

V>>Итак, если кратко: эксепшины имеют право на существование, но их применение следует ограничить исключительно исключительными ситуациями.
B>ИМХО именно для этого они и преднезначены.

Давай конкретизируем. Я не считаю невозможность открытия файла исключительной ситуацией.

[...]
V>>Эксепшин на невозможность открытия файла, преобразовать строку в число и т.п. для библиотечных классов/функций — это неправильно. Потому как это заставляет программиста, использующего эти библиотечные функции явно ловить эксепшины даже тогда, когда код возврата ему абсолютно неинтересен.
B>Не согласен. На мой взгляд разработчик библиотеки лучше знает, когда нужно, а когда не нужно обращать внимание на результат работы некоторой функции. В случае с исключением игнорировать его сложнее, чем код возврата.

Поему сложнее? Если пользователь библиотеки не удосужился обратить внимание на возможные возвращаеимые значение, он не удосужится и try/catch поставить. И все будет плохо (см.п. 2). А обработать код возврата синтаксически проще.

[...]
V>>value=default_value;
V>> f(&value);
V>>[/ccode]
B>А если нельзя по value определить — корректно отработала f или нет:?!

А оно и не надо в данном примере, т.к. есть default_value. И таких случаев не меньше, чем случаев, когда код возврата жизненно важен.

B>В общем случай с atoi в чистом виде.

B>Нет. У atoi нет дефолтового значения. Зато пользоваться ей удобнее.

B>Я согласен, что есть ситуации, когда на ошибку преобразования можно забить, и довольствоваться тем нулем, который она вернула. А если нет?!

А если нет — не надо пользоваться atoi. Я не понимаю, в чем проблема-то? И чем эксепшины здесь рулят?

[...]

V>>3) Отладка. Понять откуда и из-за чего пришел эксепшин в проге напичканной эксепшинами (без приема особых мер) бывает довольно затруднительно.
B>Повторюсь: "напичканная исключениями" программа наводит на подозрения.

Именно так и получится, если пихать эксепшины в библиотечные функции.

B>ИМХО сам термин "исключительная ситуация" указывает на то, что такие ситуации — нечто редкое...

Только для меня это нечто намного более редкое, чем для тебя

V>>А приходит он как раз из тех участков проги, в которых его никто не ожидает. В случае же непроверки кода возврата — прога просто вылетит на ближайшем assert'e.
B>При наличии этого assert'а (несколькими строчками выше кто говорил о возможности игнорирования кодов возврата... )

Нет, проверка кодов возврата и assert'ы — это разные вещи.

[...]
B>А что, такая ситуация (невозможность дальнейшей работы) возможно только при работе с портом?!

У меня таких ситуаций на практике было крайне мало. Как правило ошибка имеет смысл быть обрабатанной непосредственно на месте. И, как правило, это не фатальные ошибки.

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

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

P>В доконку хотел бы подкинуть пост из недр "знаменитого" топика "Выйти из двух циклов сразу" http://www.rsdn.ru/forum/Message.aspx?mid=61162&only=1

Автор: m.a.g.
Дата: 06.06.02

P>Как насчет данного случая? В плане применябельности эксепшенов.

Типичное извращение Особенно если циклы и затеяны был для того, чтобы найти эту самую исключительную "ситуацию". "На что только люди не идут, лишь бы goto не писать" (с) чей-то.

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

V>В философии это будут общие слова ни о чем Типа: "и то и то имеет смысл в зависимости от ситуации" и с этим трудно не согласится. Я же говорю, очень много чего зависит от средства разработки.
Ок согласен.

V>>>Итак, если кратко: эксепшины имеют право на существование, но их применение следует ограничить исключительно исключительными ситуациями.
B>>ИМХО именно для этого они и преднезначены.

V>Давай конкретизируем. Я не считаю невозможность открытия файла исключительной ситуацией.
Это зависит от конкретного приложения и от конкретной ситуации.
[...]
V>Поему сложнее? Если пользователь библиотеки не удосужился обратить внимание на возможные возвращаеимые значение, он не удосужится и try/catch поставить. При этом прога сразу завалится, что сразу же наведет на некоторые размышления
Если же просто не поставили assert или не проверили код возврата, то прога завалится "там вдали за рекой", и истинную причину будет отыскать сложнее.
V>[...]
V>>>value=default_value;
V>>> f(&value);
V>>>[/ccode]
B>>А если нельзя по value определить — корректно отработала f или нет:?!

V>А оно и не надо в данном примере, т.к. есть default_value.
Это верно для данного примера

B>>В общем случай с atoi в чистом виде.

V>А если нет — не надо пользоваться atoi. Я не понимаю, в чем проблема-то? И чем эксепшины здесь рулят?
тем, что некорректная работа не остается без внимания

V>[...]

V>>>3) Отладка. Понять откуда и из-за чего пришел эксепшин в проге напичканной эксепшинами (без приема особых мер) бывает довольно затруднительно.
B>>Повторюсь: "напичканная исключениями" программа наводит на подозрения.

V>Именно так и получится, если пихать эксепшины в библиотечные функции.
Очень спорное утверждение. "Пихать эксепшины в библиотечные функции" можно очень по-разному.

B>>ИМХО сам термин "исключительная ситуация" указывает на то, что такие ситуации — нечто редкое...

V>Только для меня это нечто намного более редкое, чем для тебя
Ну что тут сказать

V>>>А приходит он как раз из тех участков проги, в которых его никто не ожидает. В случае же непроверки кода возврата — прога просто вылетит на ближайшем assert'e.
B>>При наличии этого assert'а (несколькими строчками выше кто говорил о возможности игнорирования кодов возврата... )

V>Нет, проверка кодов возврата и assert'ы — это разные вещи.

int nRetCode = someFunc();
assert(nRetCode != FAIL);

V>[...]
B>>А что, такая ситуация (невозможность дальнейшей работы) возможно только при работе с портом?!

V>У меня таких ситуаций на практике было крайне мало. Как правило ошибка имеет смысл быть обрабатанной непосредственно на месте. И, как правило, это не фатальные ошибки.
А у меня такие ситуации нередки. И это видимо — главная причина спора

V>Для возврата "наверх" из сильно вложенного алгоритма эксепшины действительно имеют смысл. Кидать их из библиотечных функций преобразования строки в число и т.п. — плохо. Я сам кину эксепшин, если моя задача подразумевает облом всего при неудачном преобразовании.
Почему плохо? Конечно можно придумать флаг, который бы сигнализировал о результате, но всегда ли он будет проверяться? А вот с исключением прога завалится, и забывчивый программист отловит эту ситуацию в самом начале.

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

V>>Давай конкретизируем. Я не считаю невозможность открытия файла исключительной ситуацией.
B>Это зависит от конкретного приложения и от конкретной ситуации.

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

B>[...]
V>>Поему сложнее? Если пользователь библиотеки не удосужился обратить внимание на возможные возвращаеимые значение, он не удосужится и try/catch поставить.

B>При этом прога сразу завалится, что сразу же наведет на некоторые размышления
B>Если же просто не поставили assert или не проверили код возврата, то прога завалится "там вдали за рекой", и истинную причину будет отыскать сложнее.

В случае эксепшина истинную причину будет установить также сложно. И алгоритм функционирования проги также "поедет". Не вижу принципиальной разницы.

V>>А если нет — не надо пользоваться atoi. Я не понимаю, в чем проблема-то? И чем эксепшины здесь рулят?
B>тем, что некорректная работа не остается без внимания

Еще раз: не надо использовать atoi, если возможна некорректная работа. И не надо навязывать программисту проверки везде где надо и не надо — потому что это С++, а не VB.

V>>[...]
V>>Именно так и получится, если пихать эксепшины в библиотечные функции.
B>Очень спорное утверждение. "Пихать эксепшины в библиотечные функции" можно очень по-разному.

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

V>>Нет, проверка кодов возврата и assert'ы — это разные вещи.
B>

B>int nRetCode = someFunc();
B>assert(nRetCode != FAIL);
B>

B>

А это частный случай ассертов. И, кстати, в этом случае сразу ясно _где_ проблема. В отличие от.

V>>[...]
B>А у меня такие ситуации нередки. И это видимо — главная причина спора

Наверное.

V>>Для возврата "наверх" из сильно вложенного алгоритма эксепшины действительно имеют смысл. Кидать их из библиотечных функций преобразования строки в число и т.п. — плохо. Я сам кину эксепшин, если моя задача подразумевает облом всего при неудачном преобразовании.
B>Почему плохо? Конечно можно придумать флаг, который бы сигнализировал о результате, но всегда ли он будет проверяться?

Флаг это наихудшее из возможных решений.

B>А вот с исключением прога завалится, и забывчивый программист отловит эту ситуацию в самом начале.

Если она завалится на самом начале. А если нет, то он наконец найдет это место и с руганью засунет этот вызов в пустой try/catch.

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

[...]

V>>>Итак, если кратко: эксепшины имеют право на существование, но их применение следует ограничить исключительно исключительными ситуациями.
B>>ИМХО именно для этого они и преднезначены.

V>Давай конкретизируем. Я не считаю невозможность открытия файла исключительной ситуацией.

Твое личное дело О вкусах не спорят.

V>[...]
V>>>Эксепшин на невозможность открытия файла, преобразовать строку в число и т.п. для библиотечных классов/функций — это неправильно. Потому как это заставляет программиста, использующего эти библиотечные функции явно ловить эксепшины даже тогда, когда код возврата ему абсолютно неинтересен.
B>>Не согласен. На мой взгляд разработчик библиотеки лучше знает, когда нужно, а когда не нужно обращать внимание на результат работы некоторой функции. В случае с исключением игнорировать его сложнее, чем код возврата.

V>Поему сложнее? Если пользователь библиотеки не удосужился обратить внимание на возможные возвращаеимые значение, он не удосужится и try/catch поставить. И все будет плохо (см.п. 2). А обработать код возврата синтаксически проще.

Не надо ненужность механизма обосновывать небрежностью (хотел вообще то другое слово использовать ) программиста.
И потом, а если у тебя код возврата не один, а много? У тебя прикладная логика будет перемешана с логикой обработки ошибок, что явно не придаст программе стройности и надежности.

V>[...]
V>>>value=default_value;
V>>> f(&value);
V>>>[/ccode]
B>>А если нельзя по value определить — корректно отработала f или нет:?!

V>А оно и не надо в данном примере, т.к. есть default_value. И таких случаев не меньше, чем случаев, когда код возврата жизненно важен.

А кто тебе сказал, что после неудачного выполнения f у тебя default_value останется?

B>>В общем случай с atoi в чистом виде.

B>>Нет. У atoi нет дефолтового значения. Зато пользоваться ей удобнее.

B>>Я согласен, что есть ситуации, когда на ошибку преобразования можно забить, и довольствоваться тем нулем, который она вернула. А если нет?!

V>А если нет — не надо пользоваться atoi. Я не понимаю, в чем проблема-то? И чем эксепшины здесь рулят?

А если нет, не надо и эксепшенами пользоваться. В чем проблема то?

V>[...]

V>>>3) Отладка. Понять откуда и из-за чего пришел эксепшин в проге напичканной эксепшинами (без приема особых мер) бывает довольно затруднительно.
B>>Повторюсь: "напичканная исключениями" программа наводит на подозрения.

V>Именно так и получится, если пихать эксепшины в библиотечные функции.

Именно так и получается, если нет четкого представления о логике обработки ошибок в программе.

B>>ИМХО сам термин "исключительная ситуация" указывает на то, что такие ситуации — нечто редкое...

V>Только для меня это нечто намного более редкое, чем для тебя

Поскольку понятие "исключительная ситуация" формально не определено, то и спорить есть что либо она или нет бесполезено. Ты вообще читал, что у Страуструппа по этому поводу написано?

[...]

V>У меня таких ситуаций на практике было крайне мало. Как правило ошибка имеет смысл быть обрабатанной непосредственно на месте. И, как правило, это не фатальные ошибки.

Как правило, "на месте" совершенно не ясен контекст в котором ошибка возникла. Тебе не приходило в голову, что одна и та же функция может вызываться из разных мест и действия в ответ на ошибку (или "исключительную ситуацю") должны тоже быть разные? Эксепшены как раз и позволяют обработать ошибку там, где для этого есть достаточно информации.
Если же ошибка может быть обработана сразу, так естественно ее стоит обрабатывать сразу и никто не заставляет тебя кидать эксепшен в такой ситуации.

V>Для возврата "наверх" из сильно вложенного алгоритма эксепшины действительно имеют смысл. Кидать их из библиотечных функций преобразования строки в число и т.п. — плохо. Я сам кину эксепшин, если моя задача подразумевает облом всего при неудачном преобразовании.

Блин, а что она должна делать, если ей не удалось преобразовать строку в число? Возвращать 0? А почему не -1? Или ты считаешь, что 0 не может быть валидным результатом преобразования?

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

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

V>В случае эксепшина истинную причину будет установить также сложно. И алгоритм функционирования проги также "поедет". Не вижу принципиальной разницы.
Ээээ...
Может я чего-то не понимаю, но если в отладчике после возникновения исключения взглянуть не call stack, то все вопросы типа "что" и "где" сразу отпадают.

V>Еще раз: не надо использовать atoi, если возможна некорректная работа. И не надо навязывать программисту проверки везде где надо и не надо — потому что это С++, а не VB.
А если эту atoi воткнули задолго до тебя?

V>>>[...]
V>>>Именно так и получится, если пихать эксепшины в библиотечные функции.
B>>Очень спорное утверждение. "Пихать эксепшины в библиотечные функции" можно очень по-разному.

V>Я использую функцию преобразования, которая может кидать эксепшин. На каком-то этапе тестирования прога падает с этим эксепшином. Вопрос, какой из 500 вызовов этой функции виноват? А может вызов этой функции происходит внутри другой библиотечной функции?..
Я в таких случаях смотрю call stack

V>>>Нет, проверка кодов возврата и assert'ы — это разные вещи.
B>>

B>>int nRetCode = someFunc();
B>>assert(nRetCode != FAIL);
B>>

B>>

V>А это частный случай ассертов. И, кстати, в этом случае сразу ясно _где_ проблема. В отличие от.
см. выше


B>>А вот с исключением прога завалится, и забывчивый программист отловит эту ситуацию в самом начале.

V>Если она завалится на самом начале. А если нет, то он наконец найдет это место и с руганью засунет этот вызов в пустой try/catch.
Без исключений он с такой же руганью вставит в это место проверку кода возврата или asser

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

V>>Давай конкретизируем. Я не считаю невозможность открытия файла исключительной ситуацией.
M>Твое личное дело О вкусах не спорят.

У меня некая функция в процессе своей работы открывает файл. "Наверх" передается либо код возврата либо тот же эксепшин. Но в любом случае эксепшин на открытие файла не имеет никакого смысла "наверху".

V>>[...]
V>>Поему сложнее? Если пользователь библиотеки не удосужился обратить внимание на возможные возвращаеимые значение, он не удосужится и try/catch поставить. И все будет плохо (см.п. 2). А обработать код возврата синтаксически проще.

M>Не надо ненужность механизма обосновывать небрежностью (хотел вообще то другое слово использовать ) программиста.

Не понгял, ты вообще про что?

M>И потом, а если у тебя код возврата не один, а много?

И чего?

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

Стройности ей придаст обилие try/catch? Не смешно. Разбираться в проге с эксепшинами наоборот сложнее, т.к. не видно явно откуда и куда можно попасть. Почти как goto, только еще хуже goto не умеет между функциями скакать.

V>>А оно и не надо в данном примере, т.к. есть default_value. И таких случаев не меньше, чем случаев, когда код возврата жизненно важен.
M>А кто тебе сказал, что после неудачного выполнения f у тебя default_value останется?

А это стандарт де-факто для подобных функций.

V>>[...]
V>>Именно так и получится, если пихать эксепшины в библиотечные функции.
M>Именно так и получается, если нет четкого представления о логике обработки ошибок в программе.

Общие слова.

B>>>ИМХО сам термин "исключительная ситуация" указывает на то, что такие ситуации — нечто редкое...
V>>Только для меня это нечто намного более редкое, чем для тебя
M>Поскольку понятие "исключительная ситуация" формально не определено, то и спорить есть что либо она или нет бесполезено. Ты вообще читал, что у Страуструппа по этому поводу написано?

Нет. Но судя по тому, куда его несет в последнее время... ничего хорошего.

M>[...]
V>>У меня таких ситуаций на практике было крайне мало. Как правило ошибка имеет смысл быть обрабатанной непосредственно на месте. И, как правило, это не фатальные ошибки.
M>Как правило, "на месте" совершенно не ясен контекст в котором ошибка возникла.

Как правило он ясен и имеет смысл как раз на месте. Смотри пример в самом начале письма.

M>Тебе не приходило в голову, что одна и та же функция может вызываться из разных мест и действия в ответ на ошибку (или "исключительную ситуацю") должны тоже быть разные? Эксепшены как раз и позволяют обработать ошибку там, где для этого есть достаточно информации.

Давай свой пример. Мне так сходу не придумать. Желательно тоже с открытием файла. По-твоему отдельная функция вообще не знает что делает и все ошибки делегирует наверх. 90% — просто ошибка проектирования.

M>Если же ошибка может быть обработана сразу, так естественно ее стоит обрабатывать сразу и никто не заставляет тебя кидать эксепшен в такой ситуации.

Да, но только чтобы ее обработать сразу, писанины в случае с эксепшинами намного больше + потеря читабельности.

V>>Для возврата "наверх" из сильно вложенного алгоритма эксепшины действительно имеют смысл. Кидать их из библиотечных функций преобразования строки в число и т.п. — плохо. Я сам кину эксепшин, если моя задача подразумевает облом всего при неудачном преобразовании.
M>Блин, а что она должна делать, если ей не удалось преобразовать строку в число? Возвращать 0? А почему не -1? Или ты считаешь, что 0 не может быть валидным результатом преобразования?

Блин, что вы все пристали к atoi??? Более другая функция вернет ошибку, что непонятного???

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

V>>В случае эксепшина истинную причину будет установить также сложно. И алгоритм функционирования проги также "поедет". Не вижу принципиальной разницы.
B>Ээээ...
B>Может я чего-то не понимаю, но если в отладчике после возникновения исключения взглянуть не call stack, то все вопросы типа "что" и "где" сразу отпадают.

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

V>>Еще раз: не надо использовать atoi, если возможна некорректная работа. И не надо навязывать программисту проверки везде где надо и не надо — потому что это С++, а не VB.
B>А если эту atoi воткнули задолго до тебя?

Задолго до тебя могли много чего сделать не так как надо. Это не аргумент.

[...]
V>>А это частный случай ассертов. И, кстати, в этом случае сразу ясно _где_ проблема. В отличие от.
B>см. выше

Аналогично

B>>>А вот с исключением прога завалится, и забывчивый программист отловит эту ситуацию в самом начале.
V>>Если она завалится на самом начале. А если нет, то он наконец найдет это место и с руганью засунет этот вызов в пустой try/catch.
B>Без исключений он с такой же руганью вставит в это место проверку кода возврата или asser

А здесь еще есть чисто психологический момент У меня меньше раздражения по поводу своих ляпов (ассерт не поставил), нежели по поводу чужих (эксепшин кинули там, где я не ожидал).

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

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

V>>>В случае эксепшина истинную причину будет установить также сложно. И алгоритм функционирования проги также "поедет". Не вижу принципиальной разницы.
B>>Ээээ...
B>>Может я чего-то не понимаю, но если в отладчике после возникновения исключения взглянуть не call stack, то все вопросы типа "что" и "где" сразу отпадают.

V>Во-первых, в отладчике тебе придется отключить бряки на эксепшины, если ты эти эксепшины широко используешь.
Бряки я не отключаю, поскольку в моем понимании "широко" — это "не на каждом шагу". Случаются они у меня редко (ИМХО как и положено), поэтому не надоедают
V>Во-вторых, тестеров тоже будешь заставлять под отладчиком тестить?
Зачем? Пусть выявят условие при котором прога падает — дальше я сам все найду

V>Задолго до тебя могли много чего сделать не так как надо. Это не аргумент.
И все-таки обидно тратить кучу времени на поиск таких "тихих" ошибок

V>А здесь еще есть чисто психологический момент У меня меньше раздражения по поводу своих ляпов (ассерт не поставил)
try не поставил
V>, нежели по поводу чужих (эксепшин кинули там, где я не ожидал).
Насчет ожидал/не ожидал можно сказать и про тот же код возврата (ну кто бы мог подумать, что здесь ноль вернется — раньше ведь всегда единица верталась?!)
Это, как ты заметил, психология, которая суть вещь тонкая и непонятная.

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

V>>Во-первых, в отладчике тебе придется отключить бряки на эксепшины, если ты эти эксепшины широко используешь.
B>Бряки я не отключаю, поскольку в моем понимании "широко" — это "не на каждом шагу".
Случаются они у меня редко (ИМХО как и положено), поэтому не надоедают

Хм. А как же, например, чтение файла с игнорированием "неправильных" чисел?

V>>Во-вторых, тестеров тоже будешь заставлять под отладчиком тестить?
B>Зачем? Пусть выявят условие при котором прога падает — дальше я сам все найду

Я, конечно, заранее извиняюсь, но есть подозрение, что ты не отлаживал чего-то такого большого и глючного Когда баг проявляется один раз из ста запусков, и исключительно под 98-й виндой у одного тестера.

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

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

V>>>Давай конкретизируем. Я не считаю невозможность открытия файла исключительной ситуацией.
M>>Твое личное дело О вкусах не спорят.

V>У меня некая функция в процессе своей работы открывает файл. "Наверх" передается либо код возврата либо тот же эксепшин. Но в любом случае эксепшин на открытие файла не имеет никакого смысла "наверху".

Не надо под "верхом" понимать MainFrame
Верхом может быть и фукция, из которой призводится вызов данной. А может, на одну выше. Или на две, без разницы. Суть в том, что ты можешь обработать это там, где тебе удобней, и не волочить за собой код возврата. Что же касается читабельности...

Вот пример кода с обработкой кодов ошибок:

if(OpenFile())
  if(MakeSomeString(str))
    if(WriteFile(str))
      CloseFile();
    else
      DoSomething();
  else
    DoSomethingElse();
else
  DoAnotherThihg();

А вот с try/catch:

try
  {
    OpenFile();
    MakeSomeString(str);
    WriteFile();
    CloseFile();
  }
catch(CFileExeption* ) {DoSomething();}
catch(COtherExeption*) {DoSomethingElse();}

Что наглядней и короче?

V>>>[...]
V>>>Поему сложнее? Если пользователь библиотеки не удосужился обратить внимание на возможные возвращаеимые значение, он не удосужится и try/catch поставить. И все будет плохо (см.п. 2). А обработать код возврата синтаксически проще.

M>>Не надо ненужность механизма обосновывать небрежностью (хотел вообще то другое слово использовать ) программиста.

V>Не понгял, ты вообще про что?
Это я про пользователь библиотеки, который не удосужится и try/catch поставить.

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

V>Стройности ей придаст обилие try/catch? Не смешно. Разбираться в проге с эксепшинами наоборот сложнее, т.к. не видно явно откуда и куда можно попасть. Почти как goto, только еще хуже goto не умеет между функциями скакать.

try/catch у тебя будет один. Если же ты каждую функцию, которая кидает ексепшен вставляешь в отдельный try блок, то могу только принести свои соболезнования

V>>>А оно и не надо в данном примере, т.к. есть default_value. И таких случаев не меньше, чем случаев, когда код возврата жизненно важен.
M>>А кто тебе сказал, что после неудачного выполнения f у тебя default_value останется?

V>А это стандарт де-факто для подобных функций.

Да что ты говоришь? Доказательства в студию, плиз

V>>>[...]
V>>>Именно так и получится, если пихать эксепшины в библиотечные функции.
M>>Именно так и получается, если нет четкого представления о логике обработки ошибок в программе.

V>Общие слова.

Какое аргумент, такой и контраргумент.

B>>>>ИМХО сам термин "исключительная ситуация" указывает на то, что такие ситуации — нечто редкое...
V>>>Только для меня это нечто намного более редкое, чем для тебя
M>>Поскольку понятие "исключительная ситуация" формально не определено, то и спорить есть что либо она или нет бесполезено. Ты вообще читал, что у Страуструппа по этому поводу написано?

V>Нет. Но судя по тому, куда его несет в последнее время... ничего хорошего.

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

M>>[...]
V>>>У меня таких ситуаций на практике было крайне мало. Как правило ошибка имеет смысл быть обрабатанной непосредственно на месте. И, как правило, это не фатальные ошибки.
M>>Как правило, "на месте" совершенно не ясен контекст в котором ошибка возникла.

V>Как правило он ясен и имеет смысл как раз на месте. Смотри пример в самом начале письма.

Смотри ответ на пример

M>>Тебе не приходило в голову, что одна и та же функция может вызываться из разных мест и действия в ответ на ошибку (или "исключительную ситуацю") должны тоже быть разные? Эксепшены как раз и позволяют обработать ошибку там, где для этого есть достаточно информации.

V>Давай свой пример. Мне так сходу не придумать. Желательно тоже с открытием файла. По-твоему отдельная функция вообще не знает что делает и все ошибки делегирует наверх. 90% — просто ошибка проектирования.

Вот как раз у Страуструппа при обсуждении механизма ексепшенов приводятся конкретные примеры.

M>>Если же ошибка может быть обработана сразу, так естественно ее стоит обрабатывать сразу и никто не заставляет тебя кидать эксепшен в такой ситуации.

V>Да, но только чтобы ее обработать сразу, писанины в случае с эксепшинами намного больше + потеря читабельности.

Я что то не совсем понимаю. Если ты можешь обработать ошибку внутри функции, ты ее обрабатываешь без всякого эксепшена, если нет кидаешь его. Что значит "чтобы ее обработать сразу, писанины в случае с эксепшинами ...". Если ты хочешь сказать, что функция могла бы сигнализировать об ошибке не експшеном, а кодом возврата, так некоторые фукции, к примеру, CString возвращают. Что прикажешь понимать под кодом ошибки?

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


V>>>Для возврата "наверх" из сильно вложенного алгоритма эксепшины действительно имеют смысл. Кидать их из библиотечных функций преобразования строки в число и т.п. — плохо. Я сам кину эксепшин, если моя задача подразумевает облом всего при неудачном преобразовании.
M>>Блин, а что она должна делать, если ей не удалось преобразовать строку в число? Возвращать 0? А почему не -1? Или ты считаешь, что 0 не может быть валидным результатом преобразования?

V>Блин, что вы все пристали к atoi??? Более другая функция вернет ошибку, что непонятного???

Ты сам ее привел в пример. Ты говоришь, что кидать из нее ексепшен неправильно. Внимание, вопрос: что она должна делать при невозможности выполнить преобразование.

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

Знаешь, у меня сложилось впечатление, что ты смотришь на исключения как на механизм организации логики работы программы. Что в корне не верно. Если следовать такому принципу, то действительно появится обилие блоков try-catch, которые изящности и читабельности отнюдь не добавят.
ИМХО главный прикол в использовании исключений — писать только логику, не засоряя код кучей ненужных однотипных проверок. Обработка же ошибок выносится в другое место. Тогда программа читается гораздо приятнее. Другое дело, что организовать программу таким образом сложнее. Но тут уж либо серьезно отнестись к проектированию, либо валить все в одну кучу. И касается это не только исключений.
Не знаю как тебя, а меня бесят конструкции типа

RetCode = someFunc1();
if(RetCode != GOOD)
   return RetCode;

...

RetCode = someFuncN();
if(RetCode != GOOD)
   return RetCode;

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

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

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

V>>>Во-первых, в отладчике тебе придется отключить бряки на эксепшины, если ты эти эксепшины широко используешь.
B>>Бряки я не отключаю, поскольку в моем понимании "широко" — это "не на каждом шагу".
B>>Случаются они у меня редко (ИМХО как и положено), поэтому не надоедают

V>Хм. А как же, например, чтение файла с игнорированием "неправильных" чисел?
Устал повторять: бывает, что "неправильное" число можно спокойно игнорировать, а бывает — наоборот. Бывает, что ситуацию с "неправильным числом" можно обработать сразу на месте, а бывает — что нет.

V>Я, конечно, заранее извиняюсь, но есть подозрение, что ты не отлаживал чего-то такого большого и глючного Когда баг проявляется один раз из ста запусков, и исключительно под 98-й виндой у одного тестера.
Смею тебя заверить, что извиняешься не зря

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

V>>У меня некая функция в процессе своей работы открывает файл. "Наверх" передается либо код возврата либо тот же эксепшин. Но в любом случае эксепшин на открытие файла не имеет никакого смысла "наверху".
M>Не надо под "верхом" понимать MainFrame
M>Верхом может быть и фукция, из которой призводится вызов данной. А может, на одну выше. Или на две, без разницы. Суть в том, что ты можешь обработать это там, где тебе удобней, и не волочить за собой код возврата. Что же касается читабельности...

Код возврата никуда и не волочится. Более верхняя функция так или иначе интерпретирует результат более нижней, вот и все. И удобнее обрабатывать мне там, где эта ошибка возникает. А вот нахрена мне обрабатывать файловые ошибки в самой верхней функции загрузки конфига, если у меня конфиг может лежать и не в файле вовсе — не понимаю. Пусть это делают функции, непосредственно осуществляющие считывание. А на самом верху мне вообще может быть пофиг до успешности этой операции.

M>Вот пример кода с обработкой кодов ошибок:
M>
M>

M>if(OpenFile())
M>  if(MakeSomeString(str))
M>    if(WriteFile(str))
M>      CloseFile();
M>    else
M>      DoSomething();
M>  else
M>    DoSomethingElse();
M>else
M>  DoAnotherThihg();
M>

Позволю немного упростить пример:

if (!OpenFile())
  DoAnotherThihg();
else
{
  if(!WriteFile(str))
      DoSomething();

  CloseFile();
}

Т.е. CloseFile должно сработать независимо от успеха WriteFile

M>А вот с try/catch:

try
{
  OpenFile();

  try
  {
    WriteFile();
  }
  catch(CFileExeption* ) 
  {
      DoSomething();
  }

  CloseFile();
}
catch(CFileExeption* ) 
{  
  DoAnotherThihg();
}

M>Что наглядней и короче?

Ы?

[...]
V>>Стройности ей придаст обилие try/catch? Не смешно. Разбираться в проге с эксепшинами наоборот сложнее, т.к. не видно явно откуда и куда можно попасть. Почти как goto, только еще хуже goto не умеет между функциями скакать.

M>try/catch у тебя будет один. Если же ты каждую функцию, которая кидает ексепшен вставляешь в отдельный try блок, то могу только принести свои соболезнования

См. вышеприведенный пример. Переделай мне его с одним try/catch и без дублирования кода.

V>>>>А оно и не надо в данном примере, т.к. есть default_value. И таких случаев не меньше, чем случаев, когда код возврата жизненно важен.
M>>>А кто тебе сказал, что после неудачного выполнения f у тебя default_value останется?
V>>А это стандарт де-факто для подобных функций.
M>Да что ты говоришь? Доказательства в студию, плиз

Win32API

[...]
V>>Нет. Но судя по тому, куда его несет в последнее время... ничего хорошего.
M>"Вчера опять от имени народа был осужден товарищ Пастернак. Его стихов мы не читали сроду, но и без них понятно, что он враг" (с) не помню.

Я тоже могу придумать источник, которого ты не читал, и ссылаться на него в качестве доказательства. И чего?

M>>>[...]
V>>Как правило он ясен и имеет смысл как раз на месте. Смотри пример в самом начале письма.
M>Смотри ответ на пример

У тебя как раз на месте все и обрабатывается.

[...]
M>Вот как раз у Страуструппа при обсуждении механизма ексепшенов приводятся конкретные примеры.

Давай ссылку, мне интересно будет глянуть.

M>>>Если же ошибка может быть обработана сразу, так естественно ее стоит обрабатывать сразу и никто не заставляет тебя кидать эксепшен в такой ситуации.
V>>Да, но только чтобы ее обработать сразу, писанины в случае с эксепшинами намного больше + потеря читабельности.
M>Я что то не совсем понимаю. Если ты можешь обработать ошибку внутри функции, ты ее обрабатываешь без всякого эксепшена, если нет кидаешь его.

Я имел ввиду, что если мне надо обработать "на месте" OpenFile, который кидает эксепшин, то мне придется заворачивать его в try/catch, вместо простого if'a с return'ом.

[...]
V>>Блин, что вы все пристали к atoi??? Более другая функция вернет ошибку, что непонятного???
M>Ты сам ее привел в пример. Ты говоришь, что кидать из нее ексепшен неправильно. Внимание, вопрос: что она должна делать при невозможности выполнить преобразование.

Я привел ее в совершенно другом топике по совершенно другому поводу.

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

M>>А вот с try/catch:

V>
V>

V>try
V>{
V>  OpenFile();

V>  try
V>  {
V>    WriteFile();
V>  }
V>  catch(CFileExeption* ) 
V>  {
V>      DoSomething();
V>  }

V>  CloseFile();
V>}
V>catch(CFileExeption* ) 
V>{  
V>  DoAnotherThihg();
V>}
V>

M>>Что наглядней и короче?

V>Ы?


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

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

V>>>>Во-первых, в отладчике тебе придется отключить бряки на эксепшины, если ты эти эксепшины широко используешь.
B>>>Бряки я не отключаю, поскольку в моем понимании "широко" — это "не на каждом шагу".
B>>>Случаются они у меня редко (ИМХО как и положено), поэтому не надоедают

V>>Хм. А как же, например, чтение файла с игнорированием "неправильных" чисел?
B>Устал повторять: бывает, что "неправильное" число можно спокойно игнорировать, а бывает — наоборот. Бывает, что ситуацию с "неправильным числом" можно обработать сразу на месте, а бывает — что нет.

Понятно. Но что же делать с брякпоинтами при использовании такой библиотечной функции, которая кидает эксепшины, которые надо игнорировать?

V>>Я, конечно, заранее извиняюсь, но есть подозрение, что ты не отлаживал чего-то такого большого и глючного Когда баг проявляется один раз из ста запусков, и исключительно под 98-й виндой у одного тестера.
B>Смею тебя заверить, что извиняешься не зря

Пока ты меня не убедил