Подтвердить что ты не робот

Когда это целесообразно использовать коды ошибок?

В языках, поддерживающих объекты исключений (Java, С#), когда целесообразно использовать коды ошибок? Является ли использование кодов ошибок когда-либо подходящим в типичных корпоративных приложениях?

Многие известные программные системы используют коды ошибок (и соответствующую ссылку на код ошибки). Некоторые примеры включают операционные системы (Windows), базы данных (Oracle, DB2) и продукты среднего уровня (WebLogic, WebSphere). Какие преимущества предоставляют коды ошибок? Каковы недостатки использования кодов ошибок?

4b9b3361

Ответ 1

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

Для простых вещей, которые всегда будут сообщениями об ошибках, управляемых человеком, без кодов в порядке. Вы можете сказать "Файл не найден", не указав ему код ошибки. Однако, если это может быть другой компьютер на другом конце, вы должны указать коды ошибок. Вы не хотите нарушать другую систему, когда вы меняете ее на "Файл <x> not found".

Ответ 2

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

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

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

Ответ 3

Очень распространенный для интерфейсов веб-сервисов. Это очень просто и стандартно вернуть код с описанием.

Я согласен, что для большинства сценариев используется старая школа

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

Вам также нужно добавить "IF", ​​чтобы проверить, является ли возвращаемый код SUCCESS или нет, в то время как исключения идут непосредственно в блок обработки ошибок.

Ответ 4

Я новичок для, но...

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

  • в среде, в которой работает ваше приложение.

  • с коммуникацией между вашим приложением и другим объектом (веб-сервер, база данных, сокет и т.д.)

  • что драйвер устройства или устройства указывает (возможно, аппаратный сбой)?

тогда коды ошибок могут иметь смысл. Например, если ваше приложение попыталось войти в базу данных от имени вашего конечного пользователя, но БД была недоступна для проверки подлинности (DB отключен, кабель отключен), тогда компилятор кода ошибки/описания может помочь конечным пользователям, пользователь устранит проблему.

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

Надеюсь, что это поможет...

- jqpdev

Ответ 5

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

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

Наконец, как упоминалось в парах других ответов, коды ошибок являются легкими и языковыми для google (думаю, коды ошибок Windows/статьи MS KB), поэтому код ошибки с описанием того, что пошло не так, может быть лучше для конца - пользователи технического продукта.

Идея кодов ошибок полезна, но IMO они принадлежат как члены исключения или как параметры для интерфейса IErrorReporter или что-то большее, чем как возвращаемые значения метода.

Ответ 6

Коды ошибок - это старая школа. Они практически не имеют ценности.

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

Но никто не заботится об этом уровне детализации. Кто хочет поддерживать такой беспорядок. Это оставило бы вас с кодами, которые означали нечто вроде "условие A и B, но не C из-за состояния S". Это больше усилий, чем стоит попытаться выработать именно то, что это значит. Трассировка стека будет более ценной, когда расскажет вам, где в программе возникла проблема.

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

Ответ 7

С# и, возможно, Java тоже поддерживает более эффективный поток управления обработкой исключений, ключевое слово finally, которое делает вещи немного лучше, чем использование кодов ошибок. Объект исключения может содержать любой уровень детализации, безусловно, намного больше, чем код ошибки. Таким образом, объект исключения более практичен, но вы можете столкнуться с необычным случаем, когда код ошибки будет более уместным.

FWIW, С++ также поддерживает объекты исключений. Я не думаю, что С++ поддерживает ключевое слово finally (хотя, возможно, более новые С++ whatervers), но на С++ вам также нужно избегать таких вещей, как возврат внутри обработчика catch.

Ответ 8

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

Например, в C процедура "get character" возвращает следующее значение символа в ASCII, но возвращает отрицательное значение, если по какой-то причине что-то пошло не так. Затем вы отвечаете за возврат к ВАШИМ абонентам таким образом, чтобы эту ситуацию с ошибкой можно было обрабатывать, и она должна возвращаться и т.д.

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

Ответ 9

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

Возьмите коды результатов HTTP как прекрасный пример такого поведения. "200" означает "счастливый", "300" может идти в любом случае, "400" или "500" означает начало волнения.

Ответ 10

Коды ошибок, если вы хотите отправить их пользователю. Если нет, используйте исключение.