Привет!

Вот собственно и вопрос. Кто чем пользуется и почему.
Про себя: всегда только 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, 
Да вы правы.

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

Вот меня заело 

видать, реально в душу запало   

Исключения нельзя использовать в real-time приложениях - слишком большие накладные расходы, по крайней мере в .NET

Но коды ошибок есть зло.   

Для обработки ошибок - исключения (если они есть и их можно использовать), для всего остального - всё остальное  

Ситуации вроде этой

исключительными не являются, соответственно можно например вернуть -1  

С этим согласен. Но и с этим:


тоже   

Тут есть тонкость, есть коды ошибок, а есть коды возврата. И это две большие разницы 

Гы  Какая разница? Вон -1, если нет подстроки - это что?

индекс   

По сабжу - больше люблю исключения. Но юзать приходится больше коды возврата - код на С ещё никто не отменял.

Мдя. Вопрос надо было перефразировать. Это касается только .NET/Java

Сам спросил, счас будет многа букф 

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

1. Можно вообще вернуть такое значение которое бы сигнализировало об ошибке? 
Например 1 / 0 - среди целых нет такого значения которое могло бы сигнализировать о том, что произошло деление на ноль, потому тут будет ексепшн. А вот для 1.0 / 0.0 такое значение есть, и тут будет positive infinity.
Ну и конечно конструкторы из которых вообще ничего нельзя вернуть. Или прокси объекты которые осущесвляют ленивую закгрузку/инициализацию и т.п.

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

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

Плохой пример кодов возврата - COM с его HRESULT. Хороший пример - возврат функцией true/false для успеха или неудачи. ИМХО.

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


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

Приветствую!

Собственно, понятное дело, что если подстрока не нашлась в строке надыть вернуть код ошибки. Но вот с этим: 

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

Я вообще в последнее время склоняюсь что надо брать пример с перла... (для web примерно так - нет ошибки всё хорошо, есть ошибка тупо выдавать 500 или 404 и не париться)

Т.е тупо "программа выполнила фигню и будет закрыта"

Это сообщение отредактировал(а) morfus - 28.8.2009, 18:56

в принципе в unix есть переменная errno.
т.е. функция может вернуть какой-то код, и записать что-то в добавок в errno.
получится что-то вроде exception, но вложения перепишут errno, и фиг поймёшь что произошло точно.

Lazin, 
я рассуждаю проще:
язык C позволяет только коды ошибок. там - только коды ошибок.
C++,Java и т.д. позволяют коды ошибок и exceptions, которые явно более наглядны, и позволяют больше. поэтому в чисто c++/java, etc. пользуемся exception-ами,
за исключением работы с внешними модулями:
напр. приложение на C++ юзает либу на C, и т.п.

neutrino, читани, полезный материал

  Ну возможности языка С не ограничиваются CRT, под винду есть SEH, так что можно работать и с исключениями. Наверняка в других оськах есть свои нативные механизмы.

извратов - хватает.
http://www.nicemice.net/cexcept/