- 假设在应用程序开发过程中，您创建了5个不同的异常类，以便在整个代码中使用
- 然后您注意到，所有这些异常都以相同的方式处理。说出你对所有5个异常所做的一切，当它们被捕获时，你会记录一条消息。为了从抛出的异常中恢复，您不需要做任何其他事情
问题是：
相同的处理是否足够好的理由将所有5个不同的异常类替换为一个。或者，拥有5个不同的异常是否有一些真正的价值，因为它们的名称（异常类的名称）可以帮助理解问题并简化调试或任何其他原因。。。。
或者换个说法：
当您在代码中创建一个新的异常类时，是当您看到代码中可能存在对该异常的唯一处理时，还是恰当地描述了异常类名的问题？
如果以相同的方式处理异常，并且它们具有相同的字段，那么它们也可能是一个。
然而，对于5种不同的情况，具有5个不同的异常类也有一些优点。您列举了其中一个优点：它可以帮助理解代码（自文档化代码）。
另一个优点是，以后你（或某人）可能会决定在未来对其中一些异常进行不同的处理。预先抛出不同类型的异常会使实现新的异常处理变得容易得多。
也就是说，一个危险是，在异常类本身中经常会有复制粘贴的冗余代码，这是一个缺点，你必须权衡其优点。
在您的特定情况下，您可能只有一个自定义异常，通常可以处理。在抛出该异常时，您可以发送一条特定于的字符串消息，提及实际异常*的原因/位置。让适当的调用方处理此异常。
优点：防止了多个异常类（从而避免了它们的记账开销）。
您已经确定了为什么拥有多个异常会更好的一个原因。它可能会使调试变得更容易。
如果它们是检查异常，那么产生多个异常的第二个原因是，当您将一个方法声明为抛出特定异常（而不是一般异常）时，这会使针对API进行编码的人更容易理解可能发生的情况。
最后，如果您已经（一致地）创建并使用了异常，那么保留将为您提供在未来某个时候以不同方式处理异常的选项。例如，如果您的应用程序的需求发生了变化。
当你在代码中创建一个新的异常类时，你是看到代码中可以对这个异常进行唯一的处理，还是恰当地描述了异常类名的问题？
当我设计一个应用程序时，只要有一个"错误条件"，其语义不能由现有的异常充分地1描述，我就会创建一个新的异常。如何处理异常（相同或不同）根本不是一个考虑因素。。。当我正在设计代码时。
1-显然，什么是足够是一个意见问题。我当然不会为每一个细微的语义区别创建不同的例外。这就是message属性发挥作用的地方
不同的异常为处理程序提供了更多信息。如果不被滥用，这通常是一件好事。
关于您没有提到的异常，最重要的是它们是否扩展了一个公共基类？如果是这样，那么即使提供了更多细节，catch-and-throws子句仍然很简单。
通常，当我从头开始构建系统时，我最多有两个所有其他异常都扩展的基本异常——一个已检查异常和一个未检查异常。通过这种方式，我的类可以捕获通用异常，只是为了阻止代码生成的异常，并且可以像我喜欢的那样具体地对问题进行切片，以获得细粒度的解决方案。
因此，我认为以不同的方式处理异常对于在代码中创建更多信息同样重要。我认为多余的代码值得这两个原因。