Java无参数构造函数：抛出不可能的异常，还是有空的catch块？

Question

无参数构造函数抛出一个不可能的异常还是有一个空的catch块更好？比如说我有一门这样的课。

public class Foo {
    private int num;
    private String numString;

    public Foo() throws NumberFormatException {
        setNum("1");
    }

    public void setNum(String s) throws NumberFormatException {
        // In reality, complex code goes here
        num = Integer.parseInt(s);
        numString = s;
    }
}

编译器强制构造函数要么抛出NumberFormatException（这永远不会发生），要么使用try/catch块。然而，有一个空的挡块是正确的吗？这通常是不受欢迎的？

public Foo() {
    try {
        setNum("1");
    } 
    catch (NumberFormatException e) { }
}

请注意，Foo将是一个库类，其他人也会使用它，所以让一个无参数构造函数抛出一个不可能的异常会让人困惑。还要注意，真正的异常是一个自定义异常，而不是NumberFormatException，这可能会让库用户更加困惑，他们可能会觉得在没有必要的时候必须阅读自定义异常。

Answer 1

我会说这取决于您的业务关注或个人编码风格，如果您选择抛出异常，那么使用拥有和包装的异常可能会更好，如果您传递的参数不正确或没有意义，您可以抛出异常现在。

无论必须抛出NumberFormatException是什么，这都是一个公正的决定，你可以在哪里找到它。它可能在你的library类中，或者caller类中，或者在你不知道的地方。没有它，程序就会停止。

在您的情况下，您是否认为no number字符串是一个合法值，如果是，您有责任在包中保留例外。

Answer 2

既然s必须是一个数字，为什么不通过setNum（）传递一个整数，而不是当前字符串？整数总是可以解析为字符串。

Answer 3

NumberFormatException是一个RuntimeException，因此您无需将其列在throws子句中——只需假装它不存在。这适用于方法和构造函数。

RuntimeException的任何子类（包括RuntimeException本身）都是“未检查的异常”，这意味着编译器不会强制您在try/catch子句中检查它。相比之下，任何不是RuntimeException子类的Exception都很容易被称为检查异常。

如果它是一个检查过的异常（也就是说，不是RuntimeException的子类），但您确定永远无法触发它，那么捕获它是安全的。与其完全吞下它，最好将它包装在未经检查的异常周围。

try {
    thisCodeCanNeverThrowAnIOException();
}
catch (IOException e) {
    throw new AssertionError(e); // juuust in case!
}

现在你的代码已经编译好了，没有了一个throws子句来处理一个你从来没想过会被抛出的异常，但是如果由于某种错误或将来的更改，这个异常最终被抛出，你也不会隐藏一个严重的错误。

（请注意那些阅读评论的人：我最初在代码示例中抛出了新的RuntimeException（e），但Stephen C和Peter Lawrey指出，在Java1.4.2和更新版本中，AssertionError更好）。