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

Question

Является ли хорошей практикой использование пользовательских бизнес-исключений (например, BusinessRuleViolationException) для управления потоком пользовательских ошибок / пользовательских неправильных входных данных ???

Классический подход: У меня есть веб-сервис, где у меня есть 2 метода, один из которых - «проверка» (UsernameAlreadyExists ()), а другой - «создатель» (CreateUsername ()) ... Поэтому, если я хочу создать имя пользователя, я должен сделать 2 обращения к веб-службе, 1.check, 2., если проверка в порядке, создать.

А как насчет использования UsernameAlreadyExistsException? Поэтому я вызываю только 2. метод веб-службы (CrateUsername ()), который содержит проверку, и, если не удачно, он генерирует исключение UsernameAlreadyExistsException. Таким образом, конечная цель состоит в том, чтобы иметь только одну обратную связь с веб-службой, и проверка может содержаться и в других методах веб-службы (поэтому я избегаю вызова UsernameAlreadyExists () все время ..) Кроме того, я могу использовать этот вид обработки бизнес-ошибок с другими вызовами веб-службы, полностью избегая проверки до вызова.

Answer 1

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

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

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

Answer 2

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