我正在考虑一种设计，其中所有致命异常都将在 Swing 应用程序中使用自定义 UncaughtExceptionHandler 进行处理。这将包括意外的 RuntimeExceptions，但也包括在关键资源不可用或以其他方式失败时抛出的自定义异常(例如，未找到设置文件或服务器通信错误)。 UncaughtExceptionHandler 将根据特定的自定义异常执行不同的操作(对于所有未预料到的异常都是一回事)，但在所有情况下，应用程序都会向用户显示一条错误消息并退出。另一种方法是为所有未预料到的异常保留 UncaughtExceptionHandler，但处理所有其他接近其起源的致命情况。
我正在考虑的设计是否合理，或者我应该使用替代方案？用于处理致命异常的典型方法是什么？
最佳答案
通常很难找到好的异常处理策略。每种方法都有其缺点。特别是，Yours 在某种意义上是好的(处理故障的集中位置)但存在以下缺陷:
您描述的异常处理程序将对每个可能的异常进行特殊处理。随着时间的推移，它将成为您应用程序的焦点:每次添加新功能时，您还需要向处理程序添加异常处理逻辑。这意味着:
- 处理程序高度依赖于其他部分，impl 发生变化。某些功能可能会触发处理程序中的相应更改。您需要小心保持这两者同步。
- 处理程序的一致性很差(有很多原因需要更改)- 它包含您应用的所有功能的交集。
另一个问题是错误恢复。抛出异常(并向用户显示一些通知)后，用户希望继续使用该应用程序。这意味着，如果您的代码开始修改内部数据结构，然后由于异常而停止，则在允许用户进行其他交互之前，您需要撤消这些修改(或至少使数据结构恢复到可用状态)。实现这一点需要对数据的组织方式进行新的思考。一种可能的解决方案是 DB 事务。另一方面，这种表示比普通的旧数据结构更复杂，因此您需要根据您的应用程序的需求来权衡它(它是玩具/原型(prototype)吗？)
关于java - 在哪里处理致命异常，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2616577/