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

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

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

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

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

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

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

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

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

Вы также должны добавить «ЕСЛИ», чтобы проверить, является ли возвращенный код УСПЕХОМ или нет, в то время как исключения поступают непосредственно в блок обработки ошибок.

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

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

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

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

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

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

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

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

--jqpdev

Коды ошибок старого образца. Они практически не представляют никакой ценности.

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

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

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

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

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

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

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

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

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

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

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

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

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