Привет!

Вот собственно и вопрос. Кто чем пользуется и почему.
Про себя: всегда только Exception-ами. ИМХО нет случая, когда необходимо пользовать Error Code. Если необходимо использовать Error Code, значит ошибка в дизайне.

Или я еще не сталкивался с настоящими случаями в которых нужен Error Code.

PS: Тут не имеются в виду всякие там АПИ. Только ваш код.

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

естественно, это - не строгое правило, но смысл передаёт

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

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

вариант в голосовании так и не смог выбрать - и то, и то использую

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

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

А если пишешь DLL которая будет юзаться, к примеру дельфой или джавой?

Спасибо за ответы.

Вот как мне думается все эти коды возврата делают код менее удобочитаемым. Плюс эксепшены я могу объединять в классы (наследование) ошибок и ловить скажем только ошибки ввода-вывода. Если бы я использовал коды возврата, то пришлось бы перечислять все в ифах. Эксепшены кстати можно ловить все в одной точке. А управление кодами - это еще то занятие... Короче если есть ошибка - это ексепшен. Если нужен код возврата, то это не ошибка а состояние объекта. И нужно сделать дизайн по-другому.

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

ИМХО, это усложнит процесс обработки ошибок. Усложнять процесс обработки ошибок не нужно потому-что баги в ошибко-репортинге где-то хрен знает где на другом полушарии это очень и очень неприятно 

Добавлено через 40 секунд

Так построено большинство библиотек, тот-же STL 

попробую разложить по полочкам:

• исключения очень сильно упрощают код
• исключения делают код надежнее
• исключения документируют код

1. исключения очень сильно упрощают код, так как позволяют разделить алгоритм нормального выполнения программы и алгоритм аварийной работы. Код получается более прозрачный, и компактный. Самое главное подсистема обработки ошибок не влияет на семантику класса.
Пример:

не очень ясный код, неправда-ли?  

уже намного понятнее.. самое главное, в функции f1 вообще нет логики для обработки ошибок  
2. исключения делают код надежнее, в первую очередь из-за того, что исключение нельзя не обработать, как в случае с кодом ошибки, который можно легко потерять. В случае исключения проще найти причину ошибки.. так как исключение как правило несет в себе больше информации.
3. здесь все просто. 

код возврата говорит только о том, что произошла какая-то ошибка и все

здесь, мало того, что исключение содержит диагностическую информацию, оно еще и документирует код...  

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



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

Lazin, спасибо за пост.


Вот как раз об этом и речь. 

п.2.
Error Code, если :
1. не всегда exception -ы возможны, помнится на PowerTV OS их юзать было нельзя :( 
2. Если изначально написание идет в си- стиле (не с++)
3. Интерфейсы типа idl и т.д.

может когда еще.
а так  exception

Интересно отметить, что ни в одном фундаментальном фреймворке вообще нет кодов возврата. Например в .NET-е или в Java.

Интересно отметить, что ни в одном фундаментальном фреймворке вообще нет кодов возврата. Например в .NET-е или в Java.

Интересно отметить, что ни в одном фундаментальном фреймворке вообще нет кодов возврата. Например в .NET-е или в Java.

В Java - есть, но мало. Например функция удаления файла возвращает булево значение и выкидывает ексепшн. Или чтение из потока, тоже использует и коды возврата и ексепшены.

Хороший пример использования кодов: это библиотека HttpClient. Метод execute() возвращает код возврата связанный с ошибками HTTP протокола и выкидывает ексепшн когда происходят ошибки сети или парсинга HTTP-ответа.

т.е. поиск позиции подстроки в строке выбрасывает Exception? 

Добавлено через 1 минуту и 10 секунд
имел в виду ситуацию, когда подстрока в строке отсутствует

LSD, 
skyboy, 
Да вы правы.

Каким же правилом руководствоваться и в каких ситуациях?