在Java中，什么时候应该创建一个检查异常，什么时候应该是运行时异常？

小编典典

在Java中，什么时候应该创建一个检查异常，什么时候应该是运行时异常？

java

什么时候应该创建一个检查异常，什么时候应该创建一个运行时异常？

例如，假设我创建了以下类：

public class Account {
    private float balance;

    /* ... constructor, getter, and other fields and methods */

    public void transferTo(Account other, float amount) {
        if (amount > balance)
            throw new NotEnoughBalanceException();
        /* ... */
    }
}

我应该如何创建我的NotEnoughBalanceException？它应该扩展Exception还是RuntimeException？还是我应该只使用它IllegalArgumentException？

阅读 696

2020-03-21

共1个答案

小编典典

在这个话题上有很多分歧。在我的上一份工作中，我们遇到了一些实际问题，运行时异常被遗忘了，直到它们出现在生产环境中（在ageswards.com上），因此我们决定只使用已检查的异常。

在我目前的工作中，我发现在很多情况下都有很多人遇到运行时异常。

我的想法是：使用CheckedExceptions，我被迫在编译时至少要在调用方中确认异常。有了Runtime异常，编译器并没有强制我执行此操作，但是可以编写一个使我能够处理的单元测试。由于我仍然相信，早日发现错误，修复它的成本就更低，因此，我更喜欢CheckedExceptions。

从哲学的角度来看，方法调用是调用者和被调用者之间某种程度的契约。由于编译器强制使用传入的参数类型，因此让其在输出时强制使用这些类型似乎是对称的。也就是说，返回值或异常。

我的经验告诉我，当我使用检查的异常时，我得到的质量更高，即代码可以正常工作。受检查的异常可能会使代码混乱，但是有一些技术可以解决此问题。我喜欢在传递图层边界时翻译异常。例如，如果我要离开持久层，我想将SQL异常转换为持久性异常，因为下一层不关心我要持久存储到SQL数据库，但希望知道是否不能持久。我使用的另一种技术是创建简单的异常层次结构。这使我可以更清晰地编写更清晰的代码，因为我可以捕获超类，并且仅在真正重要时才处理各个子类。

2020-03-21