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

Question

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

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

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

@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();
}

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

Answer 1

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

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

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

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

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

Answer 2

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

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

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

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

Answer 3

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

Answer 4

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

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