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

S>Если я забуду обработать одну ошибку в функции, то у меня нарушится логика работы, и вероятно, не будет ни чего плохого, но если я забуду обработать два исключения ...
S>Так что уж лучше без них.

Интересный подход... Особенно "...не будет ничего плохого..."

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

S>Коллеги, хотелось бы поднять тему обработки исключений в С++ приложениях.
S>При разработке системы отслеживания и обработки ошибок в объектно-ориентированном приложении порою сталкиваешься с дилемой: какой подход и в каком случае применять для решения этих задач. Фактически речь идет о выборе между отлавливанием через try-catch, предпологающим написание классов исключений и обычным анализом возвращаемого статуса выполнения. Кто чем пользуется и в каких случаях пользуется?

Давайте конкретизируем обсуждаемый вопрос.
Предположим, для построения механизма обработки ошибок, мы взяли за основу модель исключений try-catch.
Обычным подходом в таком случае, является создание собственного класса исключения, инкапсулирующего информацию о возникшем исключении. Экземпляр этого класса создается в точке возникновения исключения, передается в catch-блок и там обрабатывается.
Вопрос вот в чем.
Что если потенциальных исключений в разрабатываемой системе достаточно много?
Ну, например, некий фрагмент логики, при работе которого может возникнуть 30-40 разного рода исключительных ситуаций.
Очевидно, что заводить свой собственный класс для каждой из потенциально возможных исключительных ситуаций — хреновое решение.
Напрашивается некоторое группирование исключений, с заведением класса исключения для каждой группы и отнесение каждого из исключений к той или иной группе.
По какому принципу стоит разбивать исключения на группы. Может быть по степени фатальноси или по подсистемам где оно возникает?
Пожалуй стоит построить иерархтю классов исключений? Какими критериями руководствоваться при решении такой задачи?
Или может быть нужен в корне другой подход?

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

S>Коллеги, хотелось бы поднять тему обработки исключений в С++ приложениях.
S>При разработке системы отслеживания и обработки ошибок в объектно-ориентированном приложении порою сталкиваешься с S>дилемой: какой подход и в каком случае применять для решения этих задач. Фактически речь идет о выборе между отлавливанием через try-catch, предпологающим написание классов исключений и обычным анализом возвращаемого статуса выполнения. Кто чем пользуется и в каких случаях пользуется?

В документации к Visual C (Exception Handling: Overview) изложен следующий подход (в моей интерпретации ):

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

б) Если какая-то ситуация возникает из-за ошибки времени разработки (например — в функцию передан нулевой указатель), т.е. требуется вмешательство программиста, то исключение не подходит, нужно использовать что-то типа ASSERT().

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

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

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

S> По какому принципу стоит разбивать исключения на
S> группы. Может быть по степени фатальноси или по подсистемам где оно
S> возникает? Пожалуй стоит построить иерархтю классов исключений?

Очень полезно посмотреть на то, как это сделано в стандартной библиотеке.

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Очень полезно посмотреть на то, как это сделано в стандартной библиотеке.

Или в MFC. (Особенно — если твоя программа на MFC, то делать исключения иных типов не рекомендуется)

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Здравствуйте, Slick, Вы писали:

S> По какому принципу стоит разбивать исключения на
S> группы. Может быть по степени фатальноси или по подсистемам где оно
S> возникает? Пожалуй стоит построить иерархтю классов исключений?

ПК>Очень полезно посмотреть на то, как это сделано в стандартной библиотеке.

А потом посмотреть, как Строуструп ругает эту самую иерархию из STL :))

You will always get what you always got
  If you always do  what you always did

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

К>ATLASSERT( SUCCEEDED( hr = pObj->Play( taram param ) ) );

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

Привет, Акул!

Ну не знаю. Я обычно исключительные ситуации использую.

А>В документации к Visual C (Exception Handling: Overview) изложен следующий подход (в моей интерпретации ):

А>а) Если возникшая ситуация отражена в протоколе функции (метода класса), то следует вернуть соответствующий код ошибки. Например — неверный пароль, переданный в функцию аутентификации.

А>б) Если какая-то ситуация возникает из-за ошибки времени разработки (например — в функцию передан нулевой указатель), т.е. требуется вмешательство программиста, то исключение не подходит, нужно использовать что-то типа ASSERT().

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

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

Исключителдьные ситуации также можно описать в описании функции. В любом случае есть гарантия, что ошибка будет замечена. Либо вызывающая функция ожидает данную исключительную ситуацию как возможный вариант исхода (try catch), либо нет — тогда тем более надо бить в колокола. Использовать коды возврата я бы рекомендовал только в случае предупреждающих ошибок. Аналог — warning-и компилятора. Хочешь показывай, хочешь — нет. Хочешь — останавливай компиляцию, хочешь — нет. В случае же ошибок надо обязательно "крикнуть". Гарантировано заметят, а следовательно ты избежишь незамеченных ошибок, а следовательно глюков программ.

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

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

D>Здравствуйте, Кодт, Вы писали:

К>>ATLASSERT( SUCCEEDED( hr = pObj->Play( taram param ) ) );

D>кое-где за такое могут и уволить профи должен знать, что случается с ассертом и выражением внутри него в релизе.

Ой-бояй! Это у меня руки быстрее головы сработали.
Конечно, там должен быть VERIFY( .... )

Кстати, нужно будет посмотреть сырцы

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

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

SKK>Обычно получаетчя примерно так:
KK>

KK>if (OK==f(x))
KK>  if (OK==f2(x))
KK>    if (OK==f3(x))
KK>    else
KK>  else
KK>else  
KK>

просто как вариант

inline bool Ok(ECODE e) { return e == OK; }
//....
  Ok(f(x)) &&
  Ok(f2(x)) &&
  Ok(f3(x));

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


AC>просто как вариант

AC>

AC>inline bool Ok(ECODE e) { return e == OK; }
AC>//....
AC>  Ok(f(x)) &&
AC>  Ok(f2(x)) &&
AC>  Ok(f3(x));
AC>

А как узнать что выстрелила f2

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

AC>

AC>inline bool Ok(ECODE e) { return e == OK; }
AC>//....
AC>  Ok(f(x)) &&
AC>  Ok(f2(x)) &&
AC>  Ok(f3(x));
AC>

Повбывав бы! Знаешь, как весело такие вещи отлаживать?
А я, увы, знаю

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

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

M>Исключения это вообще единственный надежный способ вернуть ошибку произошедшую в конструкторе (согласно Страуструпу же).
Как вам уже написали, лучше инициализацию проводить не в конструкторе, а в отдельном методе.

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

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

S>Во первых, вы используете разновидность GoTo, а это очень плохой оператор,
WH>Причем тут goto? Исключение разматывает стек.
Я имею в виду, что

try
{
...
   if ( F(...)==0 ) throw ex1 ;
....
}
catch ( ex1)
{

}

и

...
if ( F(...)==0 ) gote ex1 ;
...
ex1:...

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

S>Если я забуду обработать одну ошибку в функции, то у меня нарушится логика работы, и вероятно, не будет ни чего плохого, но если я забуду обработать два исключения ...
WH>Да и проявлятся она будет после дождичка в четверг. Именно такие ошибки труднее всего поймать, а если у тебя рухнула программа то ты покрайней мере будешь знать что она есть. А если это произошло под отладчиком то еще будешь знать где именно.
Я плохо выразил свою мысль. Если у меня в проге редкая ошибка, то в первом случая прога будет падать по крайне мерее не сразу, а по моему опыту, лучше уж, если у клиента программа работает не правильно, чем падает с сообщением Windows

S>Так что уж лучше без них.
WH>Нетуж лучше с ними.
Сколько людей, столько и мнений.

Здравствуйте, Slick
Я ознакомился с вашими доводами,и мой ответ в следующем абзаце форума

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

ssm>Здравствуйте, Alexey Chen, Вы писали:


AC>просто как вариант

AC>

AC>inline bool Ok(ECODE e) { return e == OK; }
AC>//....
AC>  Ok(f(x)) &&
AC>  Ok(f2(x)) &&
AC>  Ok(f3(x));
AC>

ssm>А как узнать что выстрелила f2

В каждом в случае f2 выбросить свой exeption

Здравствуйте, Slick

S>Какими критериями руководствоваться при решении такой задачи?
S>Или может быть нужен в корне другой подход?
Если я правильно понял, вы спрашиваете, как групировать исключительные ситуации?

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

S>Здравствуйте, Slick

S>Какими критериями руководствоваться при решении такой задачи?
S>Или может быть нужен в корне другой подход?
S>Если я правильно понял, вы спрашиваете, как групировать исключительные ситуации?

Да, именно так.

Просто интересно свежее мнение на эту тему.

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

S>Коллеги, хотелось бы поднять тему обработки исключений в С++ приложениях.
S>При разработке системы отслеживания и обработки ошибок в объектно-ориентированном приложении порою сталкиваешься с дилемой: какой подход и в каком случае применять для решения этих задач. Фактически речь идет о выборе между отлавливанием через try-catch, предпологающим написание классов исключений и обычным анализом возвращаемого статуса выполнения. Кто чем пользуется и в каких случаях пользуется?

И еще попутный вопрос.

Что лучше и по каким соображениям:

try {
   .....
}
catch (CTheException ex) {
   .....
}

или

try {
   .....
}
catch (CTheException* pEx) {
   .....
}

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

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

S>Здравствуйте, Slick

S>Какими критериями руководствоваться при решении такой задачи?
S>Или может быть нужен в корне другой подход?
S>Если я правильно понял, вы спрашиваете, как групировать исключительные ситуации?

S>Да, именно так.

S>Просто интересно свежее мнение на эту тему.

Моё мнение таково — существуют 4 вида исключительных ситуаций
1 Не критические ситуации
2 Критические ошибки — программу надо срочно сворачивать, дальше работать нет смысла
3 Программисткие ошибки — только на этапе разработки
4 Ошибки какой-то внешней среды