Код ошибки в Exception

Был когда-то в нашей команде DMSF очень горячий спор о том, следует ли в Exception-ах добавлять код ошибки, как например, у SqlException. Сегодня нашел замечание по-этому поводу в блоге Krzysztof Cwalina. Выдержка:

Do not return error codes. Exceptions are the primary means of reporting errors in frameworks. The chapter overview section describes the benefits of exceptions in detail.

Annotation (Krzysztof Cwalina): It’s ok for exceptions to have a property returning some kind of error code, but I would be very careful about this also. Each exception should carry two main pieces of information: the exception message explaining to the developer what went wrong and how to fix it and the exception type that should be used by handlers to decide what programmatic action to take. If you think you need to have a property on your exception that would return additional error code, think who this code is for. Is it for the developer or for the exception handler? If for the developer, add additional information to the message. If for the handlers, add a new exception type.

Коментарі

Анонім каже…
"Говорила - балакала. Сiла та й заплакала..."

Вспоминаем в чем, собственно проблема.
Если мы пишем курсовую работу по программированию, тогда все просто: мы определяем, какое сочетание
переменных в данно месте кода нас не устраивает и выдаем резолюцию в виде throw new Exception [type]([params]).
Далее по сценарию: мы ловим эту ошибку, отменяем последнее действие и ждем у моря погоды - все довольны
как слоны.

Ситуация усложняется, если жизненный цикл нашего творения несколько дольше, чем сдача курсовика.
тут есть несколько проблем:
1. Передача сообщения об ошибке через каналы связи;
2. Изоляция верхних слоев логики от всплывания ошибок нижних слоев;
3. Протоколирование и "локализация", с далнейшим разбором полетов.

Чаще всего ошибки (Exception) воспринимаются как "то, что программа не может исправить сама",
а на деле - ленивый программист не может предусмотреть альтернативных ход событий и позволить
другому, менее ленивому, исправить ситуацию. (коментарии про "FileNotFound","OutOfMemory", "OutOfPower",
"ProcessorCrash", "SystemPanic" и прочую лабуду сейчас не уместны).

Грубо говоря, в сложной системе, где каждый комонент, как и положено, бросает свой Exception (причем,
в идеальном случае, на каждый случай свой тип.), нельзя обойтись одними типами.
Почему:
1. при передаче по Remouting'у Exception сериализуется как класс, а значит принимающая сторона должна знать
его в лицо - что недопустимо. Можно применять исхищрения, с сурогатными десереализациями и т.п. но это
уже попытки решить проблему (естественно ее решить можно).
2. Оператор catch (Exception) такой же тупой, как и его изобретатель, по этому приходится прибегать к исхищрениям,
что бы словить все ошибки, которые не должны вылететь выше, обработать и выдать адекватный Exception или даже
что-то сделать на этот счет.
3. Eсли ошибки возникают, потом ловытся, обрабатываются, потом снова ловятся и т.д. - то стек меняется, тип и текст
меняется, а кто и что должен протоколировать? так получается много записей одного события. А архиологи потом
выясняют: "на что же, все таки, похож слон?".

Что дают коды?
Вопервых, ошибка - это не деление на ноль, а ситуация в системе, противоречащая ее семантике. Как правило,
противоречивые читуации в бизнес-логике - это защита (если хотите - забор) от неочевидных ошибок человека.
Человеком же они и должны исправляться. Другая половина - это системные ошибки, когда система не может
выполнить логичное действие (что-то сломалось, ошибка программиста). Так или иначе, но цепочка событий,
место в программе, и т.д. должны быть определены. Код - это описание ситуации. Он не решает всех проблем,
он позволяет (программисту, отладчику) понять, что произошло. Номер - это такой иероглиф, который мало
подвержен коорзии при передачах и обработках.

На что раегировать системе, если она получила MyLibraryException([message])?
на тип уже нельзя, на текст нельзя никогда. связь с ситуацией потеряна. Если бы в MyLibraryException был код,
и во всех ошибках от MyLibrary был код и спецификация кодов - можно было принимать решение (и строить
механизмы, делегирующие принятие решения) опираясь на спецификацию кодов.
Unknown каже…
2 pilya: If for the handlers, add a new exception type.
Іван каже…
2 pilya:
"Прекрасное произведение, автор, буду ждать ваших следующих произведений!"

Полностью поддерживаю.
Мы уже неоднократно сталкивались с тем, что отстуствие кода не позволяет нам сделать, то полноценную диагностику на клиенте, то упростить локализацию.
Unknown каже…
На самом деле, я тоже противник "запрета на коды". Более того, наш продукт dmsf содержит такие коды как средство упрощения локализации. Но призываю всех учитывать предпочтительность создания нового типа ошибки в большинстве ситуаций, чем введения кодов.

Популярні дописи з цього блогу

Посчитать количество вхождений каждого слова в текстовом файле

Українська мова