创建自定义异常还是使用内置异常？
目前，我正在编写一个客户端类，该类利用 DNS、套接字和 SSL 以及其他喜欢抛出异常的类。其他人将实现这个类，所以我想知道抛出异常的最佳实践是什么。
我应该创建自己的自定义异常，以便他们知道是我的类抛出异常，还是应该允许我调用的类和方法（DNS、套接字等）抛出他们自己的异常？目前，代码有数百行，并且随着许多不同的方法调用而不断增长。在这种情况下抛出异常的最佳实践是什么？
Currently I'm in the process of writing a client class that utilizes DNS, Sockets, and SSL among other classes that love to throw exceptions. Other people will be implementing this class, so I was wondering what the best practice is for throwing exceptions.
Should I create my own custom exception so they know that it is my class throwing the exception or should I allow the classes and methods I call (DNS, Sockets, etc.) to throw their own exceptions? Currently, the code is in the hundreds of lines and growing with many different method calls. What is the best practice for throwing exceptions in this situation?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
如果 BCL 包含已传达所需含义的类（例如，
ArgumentNullException），请使用这些类。为特定于您的 API 的事物保留使用您自己的异常类。
如果您觉得可以添加信息，请务必引发自己的异常，但不要吞下异常 - 将它们作为您自己的内部异常传播。
If the BCL contains classes that already convey the meaning you want (
ArgumentNullException, for instance), use those.Reserve using your own exception classes for things that are specific to your API.
If you feel that you can add information, by all means raise your own exception but do not swallow exceptions - propagate them up as inner exceptions of your own.
如果它们添加了信息，则抛出您自己的异常是可以的，但不要吞掉底层服务中的异常，除非存在安全问题。
如果您捕获一个异常并抛出一个新异常，请将旧异常分配给新异常的
InnerException属性。您可以通过这种方式嵌套尽可能多的异常，这会创建一个分层“视图”来了解异常如何传播，这对于调试非常有帮助。It is fine to throw your own exceptions if they add information, but don't swallow the exceptions from the underlying services unless there is a security concern.
If you are catching one exception and and throwing a new one, assign the old one to the
InnerExceptionproperty of the new one. You can nest as many Exceptions as necessary in this way, which creates a hierarchical "view" into how the exception propagated, which is very helpful for debugging.最糟糕的事情就是抛出一个 ApplicationException，并在消息字符串中包含详细信息。如果您发现自己需要这样做，那么是时候进行自定义例外了。
The worst thing you can do is throw an ApplicationException with details in the message string. IF you find yourself needing to do that, it's time for a custom exception.
这实际上取决于您的受众，即您所在班级的消费者。
例如，如果您本质上包装了许多不同的异常，那么创建自定义异常可能是一个好主意，这可以简化使用者中的错误处理。
如果您确实创建了自定义异常，请确保将原始异常包含到自定义异常的 InnerException 中，除非您明确有理由隐藏它。这将使人们使用您的班级获得最多的可用信息，并且如果出现您的班级未完全涵盖的异常情况，也可以为您提供帮助。
It really depends on your audience, i.e. the consumers of your class.
For example, if you are essentially wrapping a lot of different exceptions, it may be a good idea to create custom exceptions that would simplify the error handling in the consumer.
If you do create custom exceptions, be sure to include the original exception into the InnerException of your custom exception, unless you explicitly have a reason to hide it. This will people using your class the most information available, as well as cover you if an exception comes back that your class doesn't completely cover.
如果您希望任何人都能捕获异常并从中恢复，那么最好使用自定义异常类型的小型层次结构，可能按预期的可恢复程度进行组织（例如，有一个异常类型指示“发生了意外的事情，但套接字可能是仍然很好”，另一个是“套接字状态不可信，但从新的套接字连接开始可能会起作用”，另一个是“主机说你正在做的事情不会起作用，除非你有理由相信某些事情已经改变了'）。对于“捕获”代码来说，引起异常的细节通常不如违反后置条件的性质重要。
If you want anyone to catch and recover from your exceptions, it's probably best to use a small hierarchy of custom exception types, probably organized by the expected degree of recoverability (e.g. have an exception type indicating 'something unexpected happened, but the socket is probably still good', another for 'the socket state cannot be trusted, but starting over with a new socket connection might work', and another for 'the host says what you're doing won't work; don't even bother retrying unless you have reason to believe something has changed'). The particulars of what caused an exception are often less important to the 'catching' code than the nature of the violated post-conditions.