2010-05-08 4 views
17

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

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

+1

Интересный вопрос +1 –

ответ

14

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

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

+0

Красиво заявлено. +1 к вам! – David

+1

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

+1

@ Джон как обобщение, это достаточно точно. –

2

Код ошибки - старая школа. Они вообще не имеют никакой ценности.

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

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

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

+2

Исключения не имеют сложности при выполнении мелочей. В случае, когда коды ошибок подходят, когда вызывающий абонент может разумно задавать вопрос: «Возможно ли XYZ?», Например. «Возможно ли разобрать эту строку как DateTime?». В этом случае исключения не являются хорошим способом сообщить об ошибке. Коды ошибок лучше всего и быстрее, когда отказ обрабатывается непосредственным абонентом. Помните, что дешевле превратить код ошибки в исключение, чем наоборот. –

+0

Код ошибки, возвращаемый, например, 'TryParse', не является хорошим примером кода ошибки. Это только true/false. Нет необходимости назначать отдельный код ошибки для каждой возможной причины отказа метода. –

+0

-1. Ошибки/исключения могут содержать код ошибки. «Коды ошибок» могут быть не просто прямым возвратом метода. –

9

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

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

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

4

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

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

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

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

+0

+1 для хранения кодов ошибок в качестве членов исключения и идеи структуры отчетов об ошибках. Я принял ответ Лорена, потому что он лучше определил, когда нужно использовать коды ошибок. Этот ответ отлично описывает, как наилучшим образом использовать и внедрять коды ошибок. –

7

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

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

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

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

2

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

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

5

Я новичок в переполнению стека, но ...

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

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

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

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

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

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

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

--jqpdev

0

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

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

+0

Ваши клиенты не имеют дело с ошибками SOAP? Интересно. –

+0

Многие из этих существующих служб не используют SOAP и предшествуют моему прибытию в мою фирму. Я просто делаю все, что могу, с того, что мне передали. – WineSoaked

1

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

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

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

0

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

+1

Это не очень удобно, см. Ответ Лорена выше. Коды следует подавать в другие системы, люди должны быть представлены с описаниями на естественном языке, а не ... «WTF is error 666? Звучит неплохо, но я понятия не имею, что это значит» – crowne

+0

Вы можете сделать оба - начать с код ошибки, а затем дать текстовое описание: Ошибка 404 - Страница не найдена. –

+0

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

Смежные вопросы