是在代码中检查异常还是在Java中使用try-catch更好的做法？

Question

我有人向我提到，捕获所有异常并不一定是好习惯（例如，NullPointerException）。我正在寻找一个解释，这是什么时候这是一件好事，什么时候不是，为什么会这样：D

谢谢！

badPanda

Answer 1

简而言之：

已检查的异常用于捕获

未经检查的例外和错误可能会冒泡。 （这些是RuntimeException和Error）的子类。

这是因为已检查的异常是“预期的”，程序可以从中恢复。未经检查的异常是程序无法轻易恢复的原因。

Sun's tutorial说（它是关于决定你应该创建什么样的异常，但它在另一方面也是提供信息的 - 即在使用例外时）：

  

以下是底线指南：如果可以合理地期望客户端从异常中恢复，请将其作为已检查的异常。如果客户端无法执行任何操作以从异常中恢复，请将其设置为未经检查的异常。

Answer 2

要进一步了解Bozho的帖子检查异常，通常会处理您希望发生的异常，无论您的代码有多完美（例如：网络电缆已拔下，您捕获和IO异常）。您声明它们的方法抛出已检查的异常，因为其他代码必须处理如何处理这些异常。

未经检查的异常往往会用于意外情况，例如NullPointerExceptions经常冒出来，因为程序应该抛出已检查的异常，过滤的数据，设置默认值等。它们是未经检查的并且通常是意外的，因此您不必捕获它们。

这种情况在100％的情况下并非如此，但作为一种通用的方法，尤其是在Java中。

Answer 3

并且添加到bozho的答案中，它有时也取决于应用程序的类型，因为在某些情况下，您可能必须处理它以执行某些操作，并且在某些情况下，您可以将其留待处理呼叫者或最终终止。

Answer 4

你的问题的标题似乎在询问是否更好地检查并处理代码中的错误条件，或者最好是将它全部放在try块中并处理catch中的异常。

如果它很简单，一定要检查错误并处理它而不是使用try-catch。例如，如果您可以通过检查无效输入并打印“请再试”类型的消息来处理无效输入，则不会使用try-catch。

我喜欢这样思考：如果我可以巧妙地绕过异常引入的错误，请检查导致它的条件并处理它们。如果您无法轻松检查条件或轻松处理它们，请使用try-catch来处理它。

Answer 5

应该捕获不是由编程错误引起的和/或可以从中恢复的异常。其他人不应该。 在java中，一般检查异常应该在RunTimeExceptions和Errors不被捕获时被捕获。

空指针异常是由编程错误引起的，即缺少空检查，因此不应该捕获它。但是，在某些情况下，您可能希望捕获RunTimeException，仅用于在将其抛回之前进行记录。

Answer 6

RuntimeExceptions可以（大多数情况下）被视为“编程错误”。例如，考虑在检查它是否实际包含任何元素之前从堆栈中弹出一个对象。在适当的实现中，应该有一些isEmpty（）方法来检查堆栈的状态。如果程序员懒惰或忘记检查堆栈，则应抛出异常以指示编程错误。

不应该抓住这些例外。这个想法是让程序崩溃并告诉程序员他的错误。

另一方面，正如其他人所说，检查异常是预期程序可以从中恢复的例外情况。虽然这在实践中听起来是个好主意，但是当您无法真正做任何事情来解决异常原因时，通常会抛出检查异常。因此，您最终会得到许多样板代码（即try-catch-blocks，其异常块除了记录或打印异常原因外什么都不做）。 Afaik，没有新的编程语言支持检查异常，因此（甚至是JavaFX）。

Answer 7

我总是在我的代码中的一个点实现一个try...catch(Throwable)（一个Throwable真的是一个错误而你的应用程序不应该执行其中一个操作），当知道什么是非常重要的时候发生这样就可以记录下来。那个地方通常是main方法。

我还在 runnable 类中尝试了... catch（异常），或者处理例如一个可以独立于其他记录处理的记录的类。在这种情况下，即使部分处理失败，应用程序仍应继续运行 - 如果我知道将抛出什么异常并不重要 - 我捕获异常，我记录它，我中止该处理条目，然后继续前进

经验法则是，如果你打算对它采取一些措施，你应该抓住一个例外（要么中止某事的处理，运行另一个例程，要么继续前进，只要你知道你在做什么）如果你不想对此做些什么，就不要抓住它。

并且不要使用您的IDE try...catch创建者来隐藏您的异常，而是让它为方法签名添加例外。