异常处理模式

Question

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

替代方案似乎是 - 为每个异常错误情况声明一个类（尽管相关的异常会从公共基类中解除）

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

Answer 1

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

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

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

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

Answer 2

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

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

Answer 3

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

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

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

处理异常有很多模式，可以回答各种问题。可以找到相当广泛的常见和有用模式集合here。

Answer 4

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