什么时候应该因为 Java 中的异常（设计问题）而让应用程序崩溃？ [关闭]

Posted 2023-04-15

【中文标题】什么时候应该因为 Java 中的异常（设计问题）而让应用程序崩溃？ [关闭]

【英文标题】：When should one let an application crash because of an exception in Java (design issue)? [closed]

【发布时间】：2012-07-04 02:44:27

【问题描述】：

在大多数情况下，可以在 Java 中捕获异常，甚至是未经检查的异常。但是，不一定可以对此做些什么（例如内存不足）。

对于其他情况，我试图解决的问题是设计原则问题。我正在尝试建立一个设计原则或一组规则，指示何时应该放弃异常情况，即使及时发现也是如此。目标是尽量不让应用程序崩溃。

是否有人已经对此进行了集思广益和沟通？我正在寻找特定的通用案例和可能的解决方案，或拇指规则。

更新

目前的建议：

如果数据一致性受到损害，请停止运行 如果数据可以删除就停止运行 如果您对此无能为力，请停止运行（内存不足...）

如果关键服务不可用或变得不可用且无法重新启动，则停止运行

一个方法/服务应该检查它是否可以从一个稳定的状态执行它的职责，如果不能，它应该通知用户（日志）并且什么都不做

如果必须停止应用程序，请尽可能优雅地降级 在数据库事务中使用回滚 自定义异常可用于提供有关如何通过处理程序解决情况的提示 尽可能多地记录相关信息 通知开发者

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

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

【问题讨论】：

如果您的应用程序很重要（例如试运行工厂的服务器），您的应用程序必须 1) 打电话给必须修复它的人 2) 只要​​确保不会删除所有内容（数据一致性几乎永远不会受到影响）。

理想情况下，您的应用程序永远不会崩溃。但是，当数据库或相机等组件丢失或无法访问时，您的应用程序应该会正常失败。

我原以为，对于很多严重的 RuntimeExceptions，您将无法选择是否让它崩溃，除非您将最开始的代码位包装在 try...catch 中块。

当内存不足时，实际上会得到一个OutOfMemoryError。与普通的异常不同，错误应该很少在正常的应用程序中被捕获，主要是因为您对它们无能为力。

我喜欢这个。但它不应该在 Programmers.stackexchange 上吗？

【参考方案1】：

Java 和 .Net 的创建者决定使用抛出的异常对象的 TYPE 来确定何时应该捕获它以及何时应该考虑解决它，这个设计决策可能是由 C++ 处理异常的方式推动的。尽管 C++ 异常处理在许多方面都比以前的存在有所改进，但它使用异常对象的类型作为确定捕获哪些异常的主要手段并不是它更好的特性之一。

因为异常捕获是由异常类型控制的，所以没有标准的异常方法来指示失败的操作是否改变了系统中任何对象的状态，或者失败是否是由处于损坏状态的对象引起的（与一种状态相反，虽然调用者可能出乎意料并且与传入的参数不兼容，但被调用的方法会认为它是完全合法的）。在许多情况下，如果为了响应用户请求，系统调用了一个尝试做某事但不能做的方法，但该方法不会对任何对象的状态产生不利影响，并且问题不是由具有损坏状态，通常最好简单地通知用户请求的操作无法执行并继续。不幸的是，没有办法将上述类型的“无害”异常与那些表明严重的系统范围问题的异常区分开来。虽然 99% 的异常可能相对无害，但一小部分是由可能导致打开文档损坏的条件引起的。如果打开的文档已损坏，则程序立即彻底崩溃可能比让它用损坏的副本替换磁盘上的良好副本更好。

如果抛出自定义异常，可以在异常类型中包含属性，这将允许代码更有用地决定应该对异常执行什么操作。不幸的是，许多抛出的异常，无论是否无害，都不会包含这些属性。

【参考方案2】：

为什么和什么时候让一个应用程序崩溃并没有什么特别的规则……我让我的应用程序崩溃的原因如下：

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

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

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

【参考方案3】：

应用程序崩溃取决于应用程序的关键级别和部署架构。

例如，如果应用程序正在控制地球上的火箭，则应用程序不应崩溃（无法控制的情况和数据优先级除外）。

在设计应用程序时，您应该将它们设计为不会删除或更改数据存储中的数据。

得出的结论是，当应用程序崩溃时，没有硬性和快速的方法来制定规则。