异常处理模式答案

【问题标题】：Exception handling pattern异常处理模式
【发布时间】：2011-01-04 00:49:10
【问题描述】：

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

替代方案似乎是-为每个异常错误情况声明一个类（尽管相关的异常将派生自一个公共基类）

有中间立场吗？推荐的方法是什么？

【问题讨论】：

weblogs.java.net/blog/bakksjo/archive/2005/09/…

标签： java exception enums design-patterns

【解决方案1】：

回答您的具体问题：您的决定应基于您的例外处理方式和原因。您想让您的程序尽可能地万无一失，并方便地分别对每个可能的错误场景做出反应吗？然后，您确实应该为您可以识别的每个可能的错误原因创建一个异常类。否则，最好单独决定每种情况。

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

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

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

【讨论】：

非常有用的链接！谢谢我忘记了模式存储库

【解决方案2】：

这是个好问题。我相信肯定有一个中间立场。

在我看来，错误代码对于向 QA 显示错误以及客户向客户支持部门报告并返回给开发人员来说是必不可少的。

对于以编程方式处理错误，我个人不推荐错误代码，我会为每个错误类别推荐一个新类，但绝对不是每个错误。 Java 在让我们开始处理 IOException、IllegalArgumentException、UnsupportedOperationException 等异常方面做得不错。我经常在我的代码中适当地抛出和捕获这些异常。

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

【讨论】：

这就是我所倾向于的，很高兴听到其他人的声音。我需要一种让 ops、qa 和开发人员讨论错误和错误代码的通用方式。

【解决方案3】：

如果您可以概括不同错误情况下的行为，尤其是如果此类行为可以归类为行为的“类”（没有双关语），那么具有异常类层次结构是有意义的。

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

【讨论】：

听起来我的设计会受到客户端代码可能采取的操作的影响，这只能是猜测，并且可能会改变......客户端今天可能想要记录错误 A，但重试明天的事……
@treefrog - 你可以大概猜到。当您说“所有这些异常都将被几乎相同地对待”时，您越不确定，不同异常类方法的权重就越大。

【解决方案4】：

在我看来，“中间立场”是使用内部“错误代码”（常见模式，但不是很常见，IMO）作为报告/信息目的的附加信息；但不是为了决定谁捕获异常（这由异常类决定）。

【讨论】：