为什么NumberFormatException是运行时？

Question

运行时异常表示合同损坏(如NPE),如果代码没有错误,则永远不应抛出.它始终指示代码中的错误(与断言相同,但断言用于内部类错误,而运行时用于类的客户端错误).

永远不应该捕获运行时异常.

另一方面,已检查的异常是签名的一部分,应该进行捕获和处理.它们可能表示用户输入错误或外部资源问题(如IOException).

有了这一切,我无法理解为什么NumberFormatException是运行时？

Answer 1

首先,无论谁告诉你

永远不应该捕获运行时异常

对Java不太了解.不要听他们 - 他们错了.

NumberFormatException是运行时异常:选择未经检查的异常,因为它们表示编程错误.在调用之前Integer.parseInt()(例如)可以知道String 是一个有效的整数,例如这里只有一种方式:

if (str.matches("^\\d{1,8}$") {
    int myInt = Integer.parseInt(str); // will never throw NumberFormatException 
}

因此,它可以被认为是编程错误 - 程序员选择不先检查.

如果您对要解析的String的完整性/质量没有信心,则很容易理解:

try {
    // parse your string
} catch (NumberFormatException e) {
    // do something about it
}

使其成为运行时的另一个原因是它不会使代码与可能不必要的try/catch块混乱,如果您确信不会得到一个,例如,如果完全信任String数据的来源.

但是,对于像`URLFormatThingyException`这样的一些已检查的异常也可以这么说.简而言之,这有点乱. (9认同)
这个答案中使用的逻辑并不令人信服。许多异常可以通过事先手动检查条件来防止，但是，这在一定程度上违背了该方法的目的。一方面，它需要精确地重新实现方法的内部检查（因此违反了封装），另一方面它增加了无用的运行时成本。我*可以*想象的是，Java 设计者认为这个例子是一个边界案例（它*可能*是一个编程错误），并且意识到始终存在的检查异常的烦恼，决定反对它们。 (5认同)
关于NPE，也可以这样说-事先检查-！ (2认同)
有什么方法可以合理地允许“ 2147483647”同时不允许“ 2147483648”，而不必执行简单地解析值所需的大量工作？ (2认同)

Answer 2

为什么 NumberFormatException 是运行时错误？好吧，如果您有一个对话框，用户在其中输入一个值，并且该值不是数字，而是按数字进行解析，那么您会想了解这一点。例外是最好的方法吗？也许不是，但事实就是如此。