在 Java 中捕获 Throwable 的最佳实践

发布于 2024-07-26 15:37:46 字数 343 浏览 7 评论 0原文

有时,您只需要捕获 Throwable,例如,在编写调度程序队列来调度通用项目并需要从任何错误中恢复时(所述调度程序记录所有捕获的异常,但默默地记录,然后继续对其他项目执行)。

我能想到的一种最佳实践是,如果异常是 InterruptedException,则始终重新抛出该异常,因为这意味着有人中断了我的线程并想要终止它。

另一个建议(来自评论,而不是答案)是始终重新抛出 ThreadDeath

还有其他最佳实践吗?

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).

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.

Another suggestion (that came from a comment, not an answer) is to always rethrow ThreadDeath

Any other best practices?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

平安喜乐 2024-08-02 15:37:46

也许最重要的一点是,永远不要吞下受检查的异常。 我的意思是不要这样做:

try {
  ...
} catch (IOException e) {
}

除非那是您的意图。 有时,人们会吞下已检查的异常,因为他们不知道如何处理它们,或者不想(或不能)用“抛出异常”子句污染他们的接口。

如果您不知道如何处理它,请执行以下操作:

try {
  ...
} catch (IOException e) {
  throw new RuntimeException(e);
}

另一个想到的问题是确保处理异常。 读取文件应该如下所示:

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 */ }
}

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.

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 */ }
}
紫竹語嫣☆ 2024-08-02 15:37:46

取决于你正在做什么。

如果您正在开发一个供其他人使用的 API,最好重新抛出异常或将其包装到您的自定义异常中并抛出。

然而,如果您正在开发最终用户应用程序,则需要处理此异常并执行必要的操作。

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.

Whereas if you are developing an enduser application you need to handle this exception and do the needful.

够钟 2024-08-02 15:37:46

OutOfMemoryError(或者可能是它的超类 VirtualMachineError)怎么样? 我无法想象在经历了如此严重的事情之后你还能做些什么。

What about OutOfMemoryError (or perhaps its super class VirtualMachineError)? I can't imagine there is much you can do after something that serious.

寂寞花火° 2024-08-02 15:37:46

如果您正在编写一个调度程序队列,那么当异常返回给您时,除了记录它之外,没有任何意义对其进行任何操作。 Swing 事件队列基本上具有这种类型的行为。

或者,您可以为“未捕获的异常处理程序”提供一个钩子,类似于 线程组。 请注意,处理程序可能需要很长时间,并最终延误您的调度程序。

就 InterruptedException 而言:唯一关心的是您的调度循环,它应该检查一些外部状态以查看是否应该停止处理。

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.

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.

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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文