应该何时让应用程序因Java中的异常(设计问题)而崩溃？

Question

在大多数情况下,可以捕获Java中的异常,甚至是未经检查的异常.但是,不一定可能对它做一些事情(例如内存不足).

对于其他情况,我试图解决的问题是设计原则.我试图建立一个设计原则或一套规则,指出何时应该放弃特殊情况,即使及时检测到.目标是尽可能不使应用程序崩溃.

有人已经集思广益并就此进行了沟通吗？我正在寻找特定的通用案例和可能的解决方案,或拇指规则.

UPDATE

建议到目前为止:

• 如果数据一致性可能受到损害,请停止运行
• 如果可以删除数据,请停止运行
• 如果你不能做任何事情就停止运行(内存不足......)

• 如果密钥服务不可用或变得不可用且无法重新启动,则停止运行

• 方法/服务应该检查它是否可以从稳定状态执行其任务,如果不是它应该通知用户(日志)并且什么都不做

• 如果必须停止应用程序,请尽可能优雅地降级
• 在db事务中使用回滚
• 可以使用自定义异常来提供有关如何通过处理程序解决问题的提示
• 尽可能多地记录相关信息
• 通知开发人员

• 尽可能保持状态和数据的一致性

• 快速修复可能是有害的,在调试时,更好地让应用程序崩溃并详细分析导致它的原因

Answer 1

为什么以及何时让应用程序崩溃没有特定的规则……我让我的应用程序崩溃的原因如下：

1.快速修复可能会产生副作用，并且存在潜在风险。在不知道我的代码崩溃的实际原因是什么的情况下，我觉得修复该错误不合适。让应用程序崩溃会导致我的代码出现错误。

2.让代码崩溃可以帮助我更好地理解编程语言和逻辑错误。

这就是我让应用程序崩溃的原因..