exception处理模式

这是我看到的常见模式，其中与exception关联的错误代码存储为静态最终整数。 当创建要抛出的exception时，它将使用这些代码之一以及错误消息构造。 这导致该方法要抓住它必须查看代码然后决定一个行动方案。

替代似乎是 – 为每个exception错误情况声明一个类（虽然相关exception将从一个公共基类中解除）

有中间地带吗？ 推荐的方法是什么？

Answer 1

这是一个很好的问题。 我相信肯定存在中间立场。

在我看来，错误代码对于向QA显示错误以及客户向客户支持报告并返回给开发人员至关重要。

为了以编程方式处理错误，我个人不建议使用错误代码，我建议为每类错误推荐一个新类，但绝对不会针对每个错误。 Java做了一个不错的工作让我们开始使用exception，如IOException，IllegalArgumentException，UnsupportedOperationException等。我经常在我的代码中抛出并捕获这些exception。

如果您的代码应该以编程方式响应的新类别，那么您应该为它创建一个新类，扩展相应的父类。 例如UserRegistrationException或ProductException。

Answer 2

如果你可以在不同的错误情况下概括行为，特别是如果这种行为可以被分类为行为的“类”（没有双关语意），那么具有exception类层次结构是有意义的。

如果你必须捕获每一个（或几乎）每个exception，并且它们中的大多数的处理几乎相同（例如打印错误和退出），那么在其中有一个具有exception编号的类是有意义的，因为它是一个更简单的设计。

Answer 3

回答您的具体问题：您的决定应基于处理exception的方式和原因。 您是否希望尽可能简化您的程序并方便地对每个可能的错误情况做出反应？ 那么你确实应该为每个可能的错误创建一个Exception类，因为你可以识别。 否则，最好单独决定每个案例。

有许多非常常见的错误会危害整个程序的稳定性（例如ClassNotFoundException或NoSuchMethodException） – 这些错误肯定应该专门处理。 还有其他错误彼此密切相关，导致类似问题 – 这些错误可以按层次分组或组织（IOException代表与输入或输出相关的各种错误，NetworkIOException仅代表输入错误和输出错误与网络访问等有关）。

在我看来，远比exception的名称和类层次更重要的是你用它做什么：你在哪里放置你的try / catch块？ 应该为哪个日志文件写入哪些日志条目？ 谁应该收到通知？ 哪些错误消息只应呈现给管理员/开发人员？ 哪些错误应该传达给最终用户？

有许多处理exception的模式，回答各种类似的问题。 这里可以找到相当广泛的常见和有用模式集合。

Answer 4

我认为，“中间立场”是使用内部“错误代码”（通用模式，但不是非常常见，IMO）作为报告/信息目的的附加信息; 但不是用于决定谁捕获exception（这由exception类决定）。