Когда целесообразно использовать коды ошибок?
На языках, которые поддерживают объекты исключений (Java, C#), когда целесообразно использовать коды ошибок? Уместно ли использование кодов ошибок в типичных корпоративных приложениях?
Многие известные программные системы используют коды ошибок (и соответствующие ссылки на коды ошибок). Некоторые примеры включают операционные системы (Windows), базы данных (Oracle, DB2) и продукты промежуточного программного обеспечения (WebLogic, WebSphere). Какие преимущества дают коды ошибок? Каковы недостатки использования кодов ошибок?
11 ответов
В программе всегда следует использовать исключения вместо кодов ошибок. Однако исключения не могут распространяться за пределы программы. Каждый раз, когда ошибка должна покинуть программу, у вас остаются сообщения об ошибках или коды ошибок.
Для простых вещей, которые всегда будут управляемыми человеком сообщениями об ошибках без кодов, это хорошо. Вы можете сказать "Файл не найден" без указания кода ошибки. Однако, если это может быть другой компьютер на другом конце, вы должны дополнительно указать коды ошибок. Вы не хотите сломать другую систему, если измените ее на "Файл
Я не думаю, что когда-либо использовал коды ошибок в.Net, за исключением одной ситуации - когда я создавал консольное приложение, которое, как я знал, должно было вызываться из другого приложения. Это другое приложение должно было знать, когда консольное приложение вышло из строя и что пошло не так. Итак, один из примеров того, когда это будет уместно, - это когда вы знаете, что ваша программа будет вызываться другими программами, и вы хотите, чтобы они структурировали способ, чтобы они понимали ошибки.
Тем не менее, я был новичком в.NET в то время, и с тех пор никогда не использовал коды ошибок.
В качестве примечания, как парень из Windows, приятно иметь возможность вводить код ошибки и придумывать статью в КБ, поэтому код ошибки в сочетании с хорошей документацией и возможностью его найти = приятные чувства от ваших пользователей.
Очень часто встречается для интерфейсов веб-сервисов. Очень просто и стандартно вернуть код с описанием.
Я согласен, что для большинства сценариев это старая школа
Я бы сказал, что самые большие недостатки это качество кода. Вы должны добавить более сложную логику для управления кодами ошибок, в то время как исключения всплывают без необходимости использовать параметры метода или возвращаемые значения.
Вы также должны добавить "IF", чтобы проверить, является ли возвращенный код SUCCESS или нет, в то время как исключения идут непосредственно в блок обработки ошибок.
Я новичок в переполнении стека, но...
Я считаю, что коды ошибок, как правило, используются или полезны для работы с ошибочными ситуациями, которые требуют своего рода конечного пользователя, чтобы вмешаться, чтобы исправить ситуацию. Если ваш код должен обслуживаться другим разработчиком, исключения - это путь. Однако в ситуации, когда возникает проблема:
в среде, в которой работает ваше приложение
со связью между вашим приложением и каким-либо другим объектом (веб-сервером, базой данных, сокетом и т. д.)
что указывает устройство или драйвер устройства (возможно, аппаратный сбой?)
тогда коды ошибок могут иметь смысл. Например, если ваше приложение попыталось войти в базу данных от имени вашего конечного пользователя, но БД была недоступна для аутентификации (БД отключена, кабель отключен), то комбинация кода ошибки / описания может помочь конечному пользователю. пользователь исправляет проблему.
Опять же на уровне разработчика / инженера, который сможет прикоснуться к исходному коду (традиционные методы отладки и тестирования) и изменить его, использовать исключения.
Надеюсь это поможет...
--jqpdev
Я часто использую коды ошибок, когда ошибка должна быть передана пользователю, поскольку они могут быть интернационализированы. Например, в компиляторе, если есть ошибки в пользовательском коде, об ошибках можно сигнализировать в бэкэнде компилятора, в то время как внешний интерфейс может локализовать их в специфичные для языка / языка строки для использования пользователем. Однако перечисления могут быть лучше для этой цели, чем необработанные целые числа.
Я также использовал их при создании платформы "сообщений об ошибках" для приложения. Когда генерировались исключения, они генерировали код ошибки, который, когда возникло исключение, был отправлен (с журналом) на центральный сервер. Код помог организовать базу данных, чтобы мы могли просматривать журналы, связанные с конкретной ошибкой.
Наконец, как уже упоминалось в нескольких других ответах, коды ошибок просты и не зависят от языка (например, коды ошибок Windows / статьи в MS KB), поэтому для конечных пользователей может быть полезен код ошибки с описанием неисправности. технический продукт.
Идея кодов ошибок полезна, но IMO они принадлежат как члены исключений или как параметры интерфейса IErrorReporter или что-то большее, чем возвращаемые значения метода.
C# и, вероятно, Java также поддерживают лучший поток управления обработкой исключений, ключевое слово finally, что делает вещи немного лучше, чем использование кодов ошибок. Объект исключения может содержать любой уровень детализации, гораздо больше, чем код ошибки. Таким образом, объект исключения является более практичным, но вы можете столкнуться с необычным случаем, когда код ошибки будет более подходящим.
FWIW, C++ также поддерживает объекты исключений. Я не думаю, что C++ поддерживает ключевое слово finally (хотя более новые C++ могут это сделать), но в C++ вам также следует избегать таких вещей, как возврат в обработчик catch.
Коды ошибок старой школы. Они не имеют никакой ценности вообще.
Единственное возможное значение кода ошибки - то, что он может идентифицировать очень специфическое обстоятельство. Вы можете иметь код для каждой точки в кодовой базе, который может выдать исключение. Это позволит вам очень точно определить, в чем заключается проблема.
Но никому нет дела до такого уровня детализации. Кто хочет поддерживать такой беспорядок. Это оставит вас с кодами, которые означают что-то вроде "условия A и B, но не C из-за состояния S". Это больше усилий, чем стоит пытаться понять, что это значит. Трассировка стека будет более ценной, если вы сообщите, где в программе возникла проблема.
Я научился программировать компьютеры до того, как исключения стали широко распространенной техникой. Я так рад, что вместо этого мы получили исключения!
Коды ошибок были разработаны в эпоху, когда для функции единственный способ сообщить вызывающей стороне, что что-то пошло не так, - это присвоить специальное значение одному или нескольким значениям из тех, которые могут быть возвращены, и очень часто только собственное целое число или около того было доступны для возврата этого специального значения.
Например, в C подпрограмма "получить символ" возвращает значение следующего символа в ASCII, но возвращает отрицательное значение, если по какой-то причине что-то пошло не так. Затем вы несете ответственность за то, чтобы вернуться к ВАШЕМУ вызывающему абоненту таким образом, чтобы эта ситуация с ошибкой могла быть обработана, и она должна вернуться и т. Д.
Механизм исключения - это элегантный способ справиться с этим "это чрезвычайная ситуация, мы должны возвращаться из кода, пока что-то не решит проблему". Коды ошибок уступают этому.
Иногда вы не хотите сообщать пользователю слишком много информации при возникновении ошибки. Например, пользователь не может подписать новый контракт. В сообщении об ошибке указывается только что-то общее, например «Невозможно подписать новый контракт».
Это усложняет поддержку случаев, когда пользователь думает, что это неправильно. Если у вас есть код ошибки, например номер или аббревиатура, он может быть частью сообщения об ошибке. Пользователь не будет знать, что это означает, но сотрудники службы поддержки могут найти это и затем проверить, действительно ли эта конкретная причина отклонения нового контракта является ошибкой или нет.
Коды ошибок для, если вы хотите отправить их пользователю. Если нет, используйте исключение.
Я написал много веб-сервисов, которые используются другими (удаленными) приложениями. Когда с запросом дела идут плохо, клиенты более или менее настаивают на получении кода, чтобы им не пришлось проводить какое-то ужасное сравнение строк, чтобы выяснить, что пошло не так.
Возьмем HTTP-коды результатов как прекрасный пример такого поведения. "200" означает "счастливый", "300" может пойти в любую сторону, "400" или "500" означает "начать волноваться".