Question

我想知道何时在构造函数中抛出已检查的异常是有意义的。到目前为止，我在验证构造函数/方法参数时总是使用RuntimeExceptions。简短的Pro / Cons我想出了：

临

错误恢复可能（捕获）

反对：

创建新实例需要try-catch块 - ＆gt;丑

例如：

/**
 * Represents a savings-account.
 * A savings-account must always have a positive balance.
 */
public class SavingsAccount extends Account {
    /**
     * Creates a new savings-account.
     *
     * @param id      unique account identifier
     * @param balance Initial account balance (in cents).
     *                Must be greater than zero (>0).
     */
    public SavingsAccount(int id, int balance) throws AccountException {
        super(id, balance);

        if (getBalance() <= 0) {
            // TODO: Throw exception.
        }
    }
    // methods ...

我知道这是一个非常原始的例子，但它仅用于演示目的。我的直觉告诉我，在这里抛出一个检查异常是有道理的，因为如果帐户处于无效状态，构造函数的调用者可能会恢复。

OR 我应该假设构造函数的调用者知道它的前置条件（来自文档）并且总是传递有效值吗？如果没有，只需抛出一个RuntimeException。

有关此类情况的最佳提示吗？

Answer 1

检查异常是Java中的一个设计缺陷。大多数情况下，调用者无法从异常中恢复，但仍然被迫处理它。稍后出现的JVM语言（Scala，Groovy，Kotlin）都没有检查异常。 Java设计者也意识到了这一点，并提供了一些微妙的方法来绕过称为检查异常的废话，例如RuntimeException。

没有什么能阻止调用者捕获CheckedException并处理它，比如重试。你不必在他们面前让他们能够做到这一点。您可以将它放在Javadoc中，JDK中的许多方法都可以，就像您尝试从空列表中获取元素一样。 std::unique_ptr

使构造函数抛出socket.id意味着您负责清理，直到抛出异常为止。

Java：在构造函数中检查异常是否合适？

1 个答案: