何时选择选中异常/未选中异常？
我从不同的教程中了解到，“如果可以合理地期望客户端从异常中恢复，则将其设置为已检查的异常。如果客户端无法从异常中恢复，则将其设置为未检查的异常。”
我真的很想通过一些代码示例来看看前面语句的有效性。例如：
try {
br.readLine();
} catch (IOException e) {
e.printStackTrace();
}在这里，IOException被检查为Exception.So，当这个异常发生时，我应该如何恢复？在这里，我排除了异常日志记录，异常重新抛出任务，因为它们实际上并没有恢复，也就是说，让事情变得正确。那么，应该在这里应用什么修改才能从中恢复呢？
如果有一种方法可以从中恢复，那么同样的方法可以应用于以下代码：
try{
Integer.parseInt("ghg4");
}catch(NumberFormatException nfe){
}这里的NumberFormatException是一个运行时/未检查的exception.So如果有一种方法可以恢复它，那么为什么它首先被声明为运行时异常呢？
回答 3
Stack Overflow用户
发布于 2012-03-31 03:33:49
我看到了三种类型的例外。在一个极端是那些你无能为力的东西，比如NullPointerException。您将在您的代码中以非常高的级别处理此问题，或者根本不处理它。检查它将是荒谬的。
另一端是那些提供有意义信息的网站。它们是一种返回值的方式，有时是一个复杂的值，当方法已经有返回值时。它们也是一种简单的向上跳转调用堆栈的方法。(我可以写一本关于这方面的书，但我就到此为止。)EOFException 就是一个很好的例子。文件是有尽头的，你迟早会找到它，你不想每次读的时候都去检查它。在这种情况下，将调用一个已检查的异常。(我认为user1291492在这一点上会同意我的观点。)这是可能发生的，任何调用read方法的人都应该为此做好准备。他们更喜欢编译器错误而不是运行时错误。
现在，当你遇到这种类型的异常时， to put in a stack trace！这需要花费大量的时间。调用者只需要知道他命中了EOF，而不是它发生在IO系统的什么地方！此外，除非有有趣的信息要返回，否则异常本身应该是一个final static引用，只生成一次，并用于发生的每个EOF。
中间的第三种类型是Java库使用的类型，比如真正的EOFException。它们没有任何意义。要么调用者希望永远不会得到EOF (例如，他在那里放了自己的标记)，要么EOFException与NullPointerException、或具有相同的性质，他希望如此，并且不需要堆栈跟踪的麻烦和损失的处理时间。我认为问题在于Java设计人员本身--我不得不承认，当我思考这个问题时，我自己也遇到过这个问题--这是很少的--他们不确定这些异常可能属于前两类中的哪一类。即使在同一个程序中，EOFException也可能在一个地方指示程序的完全失败。在另一种情况下，这可能是发现文件已被读取的正常方式。因此，最终的结果是大量的异常既完成了这两项工作，又做得很差，迫使程序员在无法做任何事情时使用try、catch和throws，并向它们提供他们不需要的复杂堆栈跟踪。
添加：我应该明确指出，您可以通过简单地接受您已经完成读取文件并继续操作(可能是在catch块中使用break语句)来从实际的EOFException恢复。然而，还有其他合适的方法来捕获EOF，所以EOFException通常意味着像NullPointerException这样的真正问题。奇怪的是，我使用NumberFormatException的方式，我认为它应该被检查。当我想要一个数字时得到"AAA“是很常见的，这是一个用户错误，而不是编程错误。
Stack Overflow用户
发布于 2012-03-31 01:27:21
c#去掉了检查异常，我认为这是个好主意。
在我编写的代码中，我基本上遵循了c#模式，扩展了RuntimeException中的所有内容。然而，在一些地方，我使用检查异常来迫使我自己和任何使用我的代码的人响应更“正常”的异常情况
Stack Overflow用户
发布于 2012-03-31 01:28:05
在RuntimeException和Exception之间没有明确的边界。一般来说，过度使用Exception的后代会导致catch子句链(例如，用于反射处理代码)，或者只会导致不关心特定类型的catch (Exception e)。有许多不同的做法，这个问题是有争议的--也就是说，它不是那么简单，在你的应用程序中没有唯一正确的方法来设计异常。
我遵守以下规则：
- 如果异常要单独处理，并且可以与简单的输入数据错误或类似的东西区分开来-这是一个已检查的异常。
- 如果一个异常是由明显错误的输入条件或代码中的错误(如NPE)引起的-则它是运行时异常。
例如，根据这个逻辑，我将使IOException成为RuntimeException的后代。
更新:关于IOException，这不是非黑即白。但一些IOE的后代(如FileNotFoundException、MalformedURLException等)肯定是糟糕的输入。此外，当您使用ByteArray IO流(或类似的流)来处理IOE时，这也会使事情变得恼人，而这种情况从未发生过。
https://stackoverflow.com/questions/9947575
复制相似问题
腾讯云开发者
