异常处理模式
这是我看到的一种常见模式，其中与异常相关的错误代码存储为静态最终整数。当创建要抛出的异常时，它是用这些代码之一以及错误消息构造的。 这导致要捕获它的方法必须查看代码，然后决定操作过程。
另一种选择似乎是为每个异常错误情况声明一个类（尽管相关异常将从公共基类派生）
是否有中间立场？推荐的方法是什么？
It is a common pattern I see where the error codes associated with an exception are stored as Static final ints. when the exception is created to be thrown, it is constructed with one of these codes along with an error message.
This results in the method that is going to catch it having to look at the code and then decide on a course of action.
The alternative seems to be- declare a class for EVERY exception error case (although related exceptions would derieve from a common base class )
Is there a middle ground ? what is the recommended method ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
回答您的具体问题：您的决定应基于如何以及为何处理您的例外情况。您想让您的程序尽可能万无一失并方便地单独对每种可能的错误情况做出反应吗？那么您确实应该为您可以识别的每个可能的错误原因创建一个 Exception 类。否则，最好根据具体情况单独决定。
有许多非常常见的错误会危及整个程序的稳定性（例如 ClassNotFoundException 或 NoSuchMethodException） - 这些绝对应该专门处理。还有其他彼此密切相关的错误，导致类似的问题 - 这些可以很好地进行分组或分层组织（IOException 代表与输入或输出相关的所有类型的错误，NetworkIOException 仅代表输入和输出错误与网络访问等相关）。
在我看来，比异常的名称和类层次结构更重要的是你如何处理它：你将 try/catch 块放在哪里？应为哪个日志文件写入哪些日志条目？应该通知谁？哪些错误消息应该只显示给管理员/开发人员？应将哪些错误传达给最终用户？
处理异常的模式有很多种，可以回答诸如此类的各种问题。可以在此处找到相当广泛的常见且有用的模式集合。
To answer your specific question: Your decision should be based on how and why your exceptions will be processed. Do you want to make your program as foolproof as possible and conveniently react to every possible error scenario individually? Then you should indeed create an Exception class for every possible error cause you can identify. Otherwise, it is best to decide for each case individually.
There are a number of very common errors that jeopardize the stability of your entire program (such as ClassNotFoundException or NoSuchMethodException) - these should definitely be handled specifically. There are other errors that are closely related to one another, resulting in similar problems - these can very well be grouped or organized hierarchically (IOException stands for all kinds of errors related to in- or output, NetworkIOException stands only for in- and output errors related to network access, etc.).
Far more important than the exception's name and class hierarchy, in my opinion, is what you do with it: Where do you place your try/catch blocks? Which log entries should be written for which log file? Who should be notified? Which error messages should be presented only to admins/developers? Which errors should be communicated to the end user?
There are many patterns for handling exceptions, answering all sorts of questions like these. A quite extensive collection of common and useful patterns can be found here.
这是一个好问题。我相信肯定有一个中间立场。
在我看来，错误代码对于向 QA 显示错误以及客户向客户支持报告并向开发人员报告错误至关重要。
对于以编程方式处理错误，我个人不推荐错误代码，我会为每个错误类别推荐一个新类，但绝对不是每个错误都推荐一个新类。 Java 在帮助我们开始使用 IOException、IllegalArgumentException、UnsupportedOperationException 等异常方面做得不错。我经常在代码中适当的时候抛出并捕获这些异常。
如果您的代码应该以编程方式响应新的异常类别，那么您绝对应该为其创建一个新类，扩展适当的父类。例如 UserRegistrationException 或 ProductException。
This is a good question. I believe there is definitely a middle ground.
Error codes are essential in my opinion for displaying errors to QA, and for customers to report to customer support and back to developers.
For programmatically handling errors I personally don't recommend error codes, I'd recommend a new Class for each category of errors, but definitely not for every single error. Java did a decent job getting us started with Exceptions like IOException, IllegalArgumentException, UnsupportedOperationException, etc. I frequently throw and catch these when appropriate in my code.
If you have a new category of exceptions that your code should respond to programmatically then you should definitely create a new class for it, extending the appropriate parent class. For example UserRegistrationException or ProductException.
如果您可以概括不同错误情况下的行为，特别是如果可以将此类行为分类为行为“类”（没有双关语），则拥有异常类层次结构是有意义的。
如果您必须捕获每个（或几乎）每个异常，并且大多数异常的处理几乎相同（例如打印错误和退出），那么拥有 1 个带有异常编号的类是有意义的，因为它是一个更简单的设计。
If you can generalize the behavior across different error cases, especially if such behavior can be classified into "classes" of behavior (no pun intended), having an exception class hierarchy makes sense.
If you must catch EVERY (or almost) every exception anyway, and the handling of most of them is nearly identical (e.g. print error and quit), having 1 class with exception number in it makes sense as it's a simpler design.
在我看来，“中间立场”是使用内部“错误代码”（常见模式，但不是很常见，IMO）作为报告/信息目的的附加信息；但不用于决定谁捕获异常（这是由异常类决定的）。
The "middle ground", as I see it, is to use the internal "error codes" (common pattern, but not VERY common, IMO) as additional information for reporting/informational purposes; but not for deciding who catches the exception (this is determined by the exception class).