在 Java 中捕获 Throwable 的最佳实践
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/1097503/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Best practices for catching Throwable in Java
提问by ripper234
Sometimes, you just have to catch Throwable, e.g. when writing a dispatcher queue that dispatches generic items and needs to recover from any errors (said dispatcher logs all caught exceptions, but silently, and then execution is continued on other items).
有时，您只需要捕获 Throwable，例如，在编写调度通用项目并需要从任何错误中恢复的调度程序队列时（所述调度程序记录所有捕获的异常，但静默记录，然后在其他项目上继续执行）。
One best practice I can think of is to always rethrow the exception if it's InterruptedException, because this means someone interrupted my thread and wants to kill it.
我能想到的一种最佳做法是，如果它是 InterruptedException，则始终重新抛出异常，因为这意味着有人中断了我的线程并想要杀死它。
Another suggestion (that came from a comment, not an answer) is to always rethrow ThreadDeath
另一个建议（来自评论，而不是答案）是始终重新抛出ThreadDeath
Any other best practices?
还有其他最佳实践吗？
回答by cletus
Probably the most important one is, never swallow a checked exception. By this I mean don't do this:
可能最重要的是，永远不要吞下已检查的异常。我的意思是不要这样做：
try {
...
} catch (IOException e) {
}
unless that's what you intend. Sometimes people swallow checked exceptions because they don't know what to do with them or don't want to (or can't) pollute their interface with "throws Exception" clauses.
除非那是你的意图。有时人们会吞下已检查的异常，因为他们不知道如何处理它们或者不想（或不能）用“throws Exception”子句污染他们的界面。
If you don't know what to do with it, do this:
如果您不知道如何处理它，请执行以下操作：
try {
...
} catch (IOException e) {
throw new RuntimeException(e);
}
The other one that springs to mind is to make sure you deal with exceptions. Reading a file should look something like this:
另一个想到的是确保您处理异常。读取文件应如下所示：
FileInputStream in = null;
try {
in = new FileInputStream(new File("..."));;
// do stuff
} catch (IOException e) {
// deal with it appropriately
} finally {
if (in != null) try { in.close(); } catch (IOException e) { /* swallow this one */ }
}
回答by Ratnesh Maurya
Depends on what you are working on.
取决于你在做什么。
if you are developing an API to be used by some one else, its better to re-throw the Exception or wrap it into a custom exception of yours and throw.
如果您正在开发供其他人使用的 API，最好重新抛出异常或将其包装到您的自定义异常中并抛出。
Whereas if you are developing an enduser application you need to handle this exception and do the needful.
而如果您正在开发最终用户应用程序，则需要处理此异常并执行必要的操作。
回答by ashirley
What about OutOfMemoryError (or perhaps its super class VirtualMachineError)? I can't imagine there is much you can do after something that serious.
OutOfMemoryError（或者它的超类 VirtualMachineError）怎么样？我无法想象在经历了如此严重的事情之后你还能做很多事情。
回答by kdgregory
If you're writing a dispatcher queue, then by the time the exception comes back to you there's no point in doing anything with it other than logging it. The Swing event queue has basically that type of behavior.
如果您正在编写调度程序队列，那么当异常返回给您时，除了记录它之外，对它做任何事情都没有意义。Swing 事件队列基本上具有这种类型的行为。
Alternatively, you could provide a hook for an "uncaught exception handler," similar to ThreadGroup. Be aware that the handler could take a long time, and end up delaying your dispatcher.
或者，您可以为“未捕获的异常处理程序”提供一个钩子，类似于ThreadGroup。请注意，处理程序可能需要很长时间，并最终延迟您的调度程序。
As far as InterruptedException goes: the only thing that cares about that is your dispatch loop, which should be checking some external state to see if it should stop processing.
就 InterruptedException 而言：唯一关心的是您的调度循环，它应该检查一些外部状态以查看它是否应该停止处理。
