Является ли хорошей практикой генерировать исключение для методов Validate () или лучше возвращать значение bool? - PullRequest
34 голосов
/ 08 марта 2011

Рекомендуется или нет генерировать исключения из методов валидации, таких как:

ValidateDates();
ValidateCargoDetails();

Кроме этого: часто ли используется надежный шаблон проверки?

Ответы [ 6 ]

29 голосов
/ 08 марта 2011

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

15 голосов
/ 08 марта 2011

Я обычно использую visitor pattern для проверки ввода;накапливая все ошибки в списке или что-то, чтобы показать пользователю.Логика выглядит так: проверка списка ошибок валидации, если он найден, информирует пользователя, в противном случае все идет хорошо.

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

9 голосов
/ 07 июня 2013

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

3 голосов
/ 08 марта 2011

Многое зависит от того, насколько исключительны ошибки проверки, насколько важно быть корректным.

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

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

3 голосов
/ 08 марта 2011

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

Я бы пошел с возвращением логического значения и строки по причине .

0 голосов
/ 28 апреля 2017

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...