3

我正在开发一个 java web 应用程序，我有一些关于设计的问题。

基本上在其当前版本中，它在很大程度上依赖于捕获异常来确定控制流。

例如，在我的一个 spring 服务类中，我有以下方法来检查作为参数给出的电子邮件是否存在于数据库中。

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

我怀疑我目前的设计可能是错误的，但如果能阅读您对此的评论和意见，以及您认为它在多大程度上存在缺陷，我将不胜感激。

4

4 回答 4

4

一般的经验法则是例外是针对“例外”情况的。

因此，如果数据项可能存在，或者可能合理地不存在，则返回布尔值会更正常。它通常还会产生更简单、更清晰的代码。

然后，您可以为真正的异常情况（例如网络故障等）保存异常。

在某些情况下，第 3 方库可能不会给您任何选择 - 如果它们抛出异常，那么您必须处理它们！

于 2012-02-16T15:53:09.753 回答
3

我更喜欢从 checkIfEmailAddressAlreadyExists 之类的方法中返回一个布尔值，并根据返回值简单地控制流程，并为真正的异常情况留下异常，例如无法连接到数据库。

于 2012-02-16T15:52:23.777 回答
3

服务模型中的验证方法不应捕获异常。这很糟糕，有几个原因：

  • 这不是一个例外情况。“没有结果”是一种常见的情况。

  • 它间接地将您的验证与框架的数据检索方法的实现结合起来。要了解为什么这不好，请想象一下您的框架是否发生了变化，以至于它现在引发了一个EmptyResultSetException. 您必须更新所有验证方法。哎呀！

如果您的底层框架引发异常以指示“无结果”，您不一定能提供帮助，但您当然可以控制什么checkIfEmailAddressAlreadyExists。

更改此方法，使其true在地址存在时返回，false如果不存在或未找到结果则返回。

于 2012-02-16T15:54:33.150 回答
1

我不是Java程序员，实际上从未使用过它。

但我确实知道在 C# 世界中引发和捕获异常非常昂贵。因此，与您自己检查事物并为您不认为DNA所说的事物留下异常相比，用它们控制流程非常低效。

于 2012-02-16T16:01:02.037 回答