创建自定义异常还是使用内置异常？

Question

目前，我正在编写一个客户端类，在其他喜欢抛出异常的类中使用DNS，套接字和SSL。其他人将实现这个课程，所以我想知道抛出异常的最佳做法是什么。

我应该创建自己的自定义异常，以便他们知道这是我的类抛出异常，还是应该允许我调用的类和方法（DNS，套接字等）抛出自己的异常？目前，代码有数百行，并且随着许多不同的方法调用而增长。在这种情况下抛出异常的最佳做法是什么？

Answer 1

如果BCL包含已传达您想要的含义的类（例如ArgumentNullException），请使用这些类。

使用您自己的异常类保留特定于API的内容。

如果您认为可以添加信息，请务必提出自己的异常但不要吞下异常 - 将它们作为您自己的内部异常传播。

Answer 2

如果他们添加信息，可以抛出自己的异常，但除非存在安全问题，否则不要从底层服务中吞下异常。

如果要捕获一个异常并抛出一个新异常，请将旧异常分配给新异常的InnerException属性。您可以通过这种方式嵌套尽可能多的异常，从而创建异常传播方式的分层“视图”，这对于调试非常有用。

Answer 3

您可以做的最糟糕的事情是在消息字符串中抛出一个包含详细信息的ApplicationException。如果您发现自己需要这样做，那么就应该进行自定义异常了。

Answer 4

这实际上取决于您的受众，即您班级的消费者。

例如，如果您实质上包含了很多不同的异常，那么创建自定义异常可能会更好，这可以简化消费者的错误处理。

如果您确实创建了自定义异常，请确保将原始异常包含在自定义异常的InnerException中，除非您明确有理由隐藏它。这将是人们使用您的课程提供的最多信息，以及如果您的课程没有完全覆盖的例外情况，则会为您提供保险。

Answer 5

如果您希望任何人捕获并从异常中恢复，最好使用自定义异常类型的小层次结构，可能由预期的可恢复性程度组织（例如，有一个异常类型指示'意外发生的事情，但是套接字可能仍然很好'，另一个'套接字状态不能被信任，但是重新开始使用新的套接字连接可能有效'，另一个用于'主机说你正在做什么将无法工作;甚至不行打扰重试，除非你有理由相信某些事情发生了变化'）。引起异常的细节通常对于“捕获”代码而言不如违反后置条件的性质重要。