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

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

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

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

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

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

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

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

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