2012-02-16 2 views
2

Я работаю над веб-приложением Java, и у меня есть несколько вопросов относительно дизайна.Проблема проектирования: в какой мере я должен полагаться на исключения для потока контроля?

В основном в его текущей версии он в значительной степени полагается на отлавливание исключений для определения потока управления.

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

@Override 
public boolean validateEmailAddressDoesNotExist(String accountEmailAddress) { 
    try { 
     return !dao.checkIfEmailAddressAlreadyExists(accountEmailAddress); 
    } catch (NoResultException re) { 
     log.error("NoResultException", re); 
    } catch (RuntimeException re) { 
     log.error("RuntimeException", re); 
    } 
    return true; 
} 

//from "dao" class 
public boolean checkIfEmailAddressAlreadyExists(String accountEmailAddress) { 
    return (loadAccountFromAccountEmailAddress(accountEmailAddress) == null ? false : true); 
} 

//also from "dao" class 
public Account loadAccountFromAccountEmailAddress(String accountEmailAddress) { 
    return entityManager.createNamedQuery("Account.findByEmailAddress", Account.class).setParameter("accountEmailAddress", accountEmailAddress).getSingleResult(); 
} 

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

+1

Это, вероятно, больше подходит для http://codereview.stackexchange.com/ –

+0

@ Все: спасибо за ваши ответы !! – balteo

+0

@ Rich.Okelly: не знал об этом сайте. Это тоже очень интересно. Я буду использовать это в следующий раз, когда у меня возникнет такой вопрос, как этот ... – balteo

ответ

3

Методы валидации в вашей модели обслуживания не должны ловить исключения. Это плохо по нескольким причинам:

  • Это не исключительное условие. «Нет результатов» - обычная ситуация.

  • Это косвенно связывает с вашей проверкой на внедрение методов поиска данных в рамках каркаса. Чтобы понять, почему это нехорошо, представьте, изменится ли ваша инфраструктура таким образом, что теперь она вызывает EmptyResultSetException. Вам нужно будет обновить все ваши методы проверки. Хлоп!

Вы не можете обязательно поможет, если ваша основная структура вызывает исключения для указания «нет результатов», но вы можете, конечно, контролировать то, что делает checkIfEmailAddressAlreadyExists.

Измените этот метод так, чтобы он возвращал true, если адрес существует, и false, если он недействителен или если результаты не найдены.

3

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

4

Общее правило заключается в том, что исключения предназначены для «исключительных» условий.

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

Вы можете сохранить исключения для действительно исключительных условий, таких как сетевые сбои и т.д.

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

1

Я не программист на Java, никогда не использовал его на самом деле.

Но я знаю, что сбор и перехват исключений очень дорог в мире C#. Таким образом, контроль потока с ними очень неэффективен, а не проверяет себя и оставляет исключения для вещей, о которых вы не думали, так как DNA сказал.