我从各种教程中了解到“如果可以合理地期望客户端从异常中恢复，则将其设置为受检查的异常。如果客户端无法执行任何操作来从异常中恢复，则将其设置为未检查的异常。”
我很想通过一些代码示例来看看前面的语句的有效性。
例如
try {
br.readLine();
} catch (IOException e) {
e.printStackTrace();
}
这里，IOException是检查异常。那么，当这个异常发生时我应该如何恢复呢？在这里，我排除了异常日志记录、异常重新抛出任务，因为它们实际上并未恢复，即使事情正确。那么，这里应该应用什么修改来恢复呢？
如果有办法从中恢复，那么可以将相同的方法应用于以下代码：
try{
Integer.parseInt("ghg4");
}catch(NumberFormatException nfe){
}
这里 NumberFormatException 是一个运行时/未经检查的异常。因此，如果有办法从中恢复，那么为什么首先将其声明为运行时异常呢？
我看到三种类型的异常。一种极端是您无能为力的异常，例如 NullPointerException。您将在代码中以非常高的级别处理这个问题，或者根本不处理。如果去检查的话那就太可笑了。
另一端是提供有意义信息的。它们是一种返回值的方式，有时是复杂的，当方法已经有返回值时。它们也是跳转调用堆栈的简单方法。 （我可以写一本关于这个的书，但我就到此为止。） EOFExceptionought就是一个很好的例子。文件有其结尾，您迟早会遇到它，并且您不想每次读取时都检查它。在这种情况下，需要检查异常。 （我认为 user1291492 会同意我的观点。）这种情况有可能发生，任何调用 read 方法的人都应该为此做好准备。他们更喜欢编译器错误而不是运行时错误。
Now,除了这种类型的例外，您do not想要放入堆栈跟踪！这要花费很多时间。调用者只需要知道他击中了 EOF，而不是它发生在 IO 系统深处的哪个位置！此外，除非有有趣的信息要返回，否则异常本身应该是final static引用，生成一次并用于发生的每个 EOF。
中间的第三种类型是 Java 库使用的类型，例如realEOF异常。他们没有任何意义。要么调用者期望永远不会得到 EOF（例如，他将自己的标记放在那里），并且 EOFException 与 NullPointerException 具有相同的性质，or他期望它，并且不需要堆栈跟踪的麻烦和损失的处理时间。我认为问题在于 Java 设计者本身（我必须承认，当我想到这个问题时，我自己也遇到过这个问题）（这种情况很少发生），他们不确定这些异常可能属于前两类中的哪一类。即使在同一个程序中，在一处 EOFException 也可能表明程序完全失败。在另一种情况下，这可能是查明文件已被读取的正常方法。所以最终的结果是大量的异常，它们既完成了这两项工作，又做得很差，迫使程序员使用try and catch and throws当他们无论如何都无法做任何事情并向他们提供他们不需要的复杂堆栈跟踪时。
添加：我应该明确指出，您可以通过简单地接受您已完成读取文件并继续操作来从真正的 EOFException 中恢复，可能使用break中的声明catch堵塞。然而，还有其他正确的方法来捕获 EOF，因此 EOFException 通常意味着像 NullPointerException 这样的真正问题。奇怪的是，我使用 NumberFormatException 的方式，我认为should被检查。当我想要一个号码时得到“AAA”是很常见的，这是用户错误，而不是编程错误。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
