Должно ли нарушение бизнес-правила создавать исключение?

Question

Должно ли нарушение бизнес-правила генерировать исключение?

Answer 1

Нет. Это часть обычной логики условной обработки в программе (и часто просто замаскированная форма ошибки пользователя).

Answer 2

Это зависит от бизнес-правила, IMO. Я рискнул бы сказать «не обычно», но я бы рассматривал это в каждом конкретном случае. Я не думаю, что есть какой-то один ответ, так как разные бизнес-правила могут это оправдать, а другие - нет.

Answer 3

Сначала пара цитат из главы 18 «Прикладное программирование на Microsoft .NET Framework» (стр. 402). Автор: Джеффри Рихтер :

«Другое распространенное заблуждение состоит в том, что« исключение »идентифицирует« ошибку »."

"Исключением является нарушение неявных предположений программного интерфейса."

Если я правильно понял из вашего вопроса, что нарушением бизнес-правила могут быть данные, которые выходят за пределы определенного диапазона (например), это ошибка, которую вы можете обработать с помощью условного выражения, как предложил @ahockley. Основываясь на определении исключения из Рихтера, целесообразно использовать исключение, если ваш код не смог извлечь бизнес-правило из какого-либо репозитория, который вы используете. Возможность извлечения бизнес-правила была бы разумным неявным предположением для этого интерфейса, поэтому следует исключение, если это предположение было нарушено.

Один хороший пример первой цитаты Рихтера (исключение! = Ошибка) - исключение ThreadAbortException. Если вы вызываете Response.Redirect (url) (в ASP.NET), выдается исключение ThreadAbortException, даже если перенаправление выполняется успешно. Зачем? Неявное предположение о выполнении страницы ASP.NET заключается в том, что страница будет выполняться полностью. Response.Redirect (url) нарушает это предположение, отсюда и исключение.

Answer 4

Нет Нарушение бизнес-правила является проблемой БИЗНЕСА, где исключение является техническим. Нарушение бизнес-правила - это то, что система должна рассматривать как нормальную работу и для которой она должна иметь запрограммированный ответ, а не исключение.

Answer 5

Вы имеете в виду, например, что значение должно быть в диапазоне 0-99, но каким-то образом оказалось 105?

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

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

Answer 6

Из-за того, как я выполняю свою валидацию и использую LINQtoSQL для ORM, да. Если объект не проходит проверку бизнес-правила во время метода OnValidate, единственный способ уведомить вызывающий код - вызвать исключение. В этом случае я выбрасываю специальное исключение DataValidationException. Использование ловушки метода OnValidate в частичной реализации класса позволяет мне выполнить проверку при обновлении / вставке, чтобы в базу данных сохранялись только действительные данные.

РЕДАКТИРОВАТЬ Я должен прояснить, что я обычно делаю проверку пользовательского ввода на клиенте, поэтому проверка уровня постоянства, как правило, является более страховой и редко, если вообще когда-либо, дает сбой. Я не обрабатываю проверку на стороне клиента как исключения, а скорее с условной логикой.

Answer 7

Как альтернативный взгляд на большинство ответов ...

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

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

Итак, подводим итоги ... Это зависит ...

Answer 8

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

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

Answer 9

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

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

Answer 10

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

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