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

Ответ 1

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

Ответ 2

Это зависит от того, что такое бизнес-правило, ИМО. Я бы рискнул сказать "не обычно", но я бы посмотрел его на индивидуальной основе. Я не думаю, что есть какой-то один ответ, поскольку другие бизнес-правила могут гарантировать это, в то время как другие могут не быть.

Ответ 3

Во-первых, пара цитат из главы 18 прикладного программирования Microsoft.NET Framework (страница 402) на Джеффри Рихтер:

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

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

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

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

Ответ 4

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

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

Ответ 5

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

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

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

Ответ 6

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

Ответ 7

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

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

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

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

Ответ 8

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

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

Ответ 9

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

Ответ 10

Это действительно зависит от того, что это такое и где оно находится.

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

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

Это часто вопрос перспективы и дизайн вашего приложения.

Ответ 11

Обычно я помещаю условие в объект Specification, который реализует

bool IsVerfiedBy(T entity);

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

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

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

Ответ 12

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

Как правило, бизнес-правила выводят ошибки и предупреждающие сообщения в область проверки.

Ответ 13

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

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

Ответ 14

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

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