在大多数情况下，可以在 Java 中捕获异常，甚至是未经检查的异常。但是，不一定可以对此做些什么（例如内存不足）。
对于其他情况，我试图解决的问题是设计原则问题。我正在尝试建立一个设计原则或一组规则，指示何时应该放弃异常情况，即使及时发现也是如此。目标是尽量不让应用程序崩溃。
是否有人已经对此进行了头脑风暴并进行了沟通？我正在寻找特定的通用案例和可能的解决方案，或拇指规则。
更新
到目前为止的建议：
如果关键服务不可用或变得不可用且无法重新启动，则停止运行
方法/服务应该检查它是否可以从稳定状态执行其职责，如果不能，它应该通知用户（日志）并且什么都不做
尽可能保持状态和数据的一致性
快速修复可能是有害的，在调试时，最好让应用程序崩溃并详细分析导致它的原因
Java 和 .Net 的创建者决定使用抛出的异常对象的 TYPE 来确定何时应该捕获它以及何时应该考虑解决它，这个设计决策可能是由 C++ 处理异常的方式推动的。尽管 C++ 异常处理在许多方面都比以前存在的改进了，但它使用异常对象的类型作为确定捕获哪些异常的主要手段并不是它更好的特性之一。
因为异常捕获是由异常类型控制的，所以没有标准的异常方法来指示失败的操作是否改变了系统中任何对象的状态，或者失败是否是由处于损坏状态的对象引起的（与一种状态，虽然调用者可能出乎意料并且与传入的参数不兼容，但被调用的方法会认为它是完全合法的）。在许多情况下，如果为了响应用户请求，系统调用了一个尝试做某事但不能做的方法，但该方法不会对任何对象的状态产生不利影响，并且问题不是由具有损坏状态，通常最好简单地通知用户请求的操作无法执行并继续。很遗憾，没有办法将上述类型的“无害”异常与表示严重系统范围问题的异常区分开来。虽然 99% 的异常可能相对无害，但一小部分是由可能导致打开文档损坏的条件引起的。如果打开的文档已损坏，则程序立即彻底崩溃可能比让它用损坏的副本替换磁盘上的良好副本更好。
如果抛出自定义异常，可能会在异常类型中包含属性，这将允许代码更有用地决定应该对异常执行什么操作。不幸的是，许多抛出的异常，无论是否无害，都不会包含这些属性。
应用程序崩溃取决于应用程序的关键级别和部署架构。
例如，如果应用程序从地球控制火箭，则应用程序不应崩溃（不可控情况和数据优先级除外）。
在设计应用程序时，您应该将它们设计为不会删除或更改数据存储中的数据。
得出的结论是，当应用程序崩溃时，没有硬性和快速的方法来制定规则。
为什么以及何时让应用程序崩溃并没有特别的规则……我让我的应用程序崩溃的原因如下：
1.快速修复可能会产生反作用并且存在潜在风险。在不知道我的代码崩溃的实际原因是什么的情况下，我觉得修复这个错误是不合适的。让应用程序崩溃会导致我的代码出现错误。
2.让代码崩溃有助于我更好地理解编程语言和逻辑错误。
这就是我让应用程序崩溃的原因..