Josh Bloch在《Effective Java》中广泛地讨论了这个主题。他的建议很有启发性，也适用于。net(细节除外)。

特别地，例外应用于特殊情况。原因主要与可用性有关。对于一个给定的方法，要最大限度地使用，它的输入和输出条件应该受到最大限度的约束。

例如，第二种方法比第一种方法更容易使用:

/**
 * Adds two positive numbers.
 *
 * @param addend1 greater than zero
 * @param addend2 greater than zero
 * @throws AdditionException if addend1 or addend2 is less than or equal to zero
 */
int addPositiveNumbers(int addend1, int addend2) throws AdditionException{
  if( addend1 <= 0 ){
     throw new AdditionException("addend1 is <= 0");
  }
  else if( addend2 <= 0 ){
     throw new AdditionException("addend2 is <= 0");
  }
  return addend1 + addend2;
}

/**
 * Adds two positive numbers.
 *
 * @param addend1 greater than zero
 * @param addend2 greater than zero
 */
public int addPositiveNumbers(int addend1, int addend2) {
  if( addend1 <= 0 ){
     throw new IllegalArgumentException("addend1 is <= 0");
  }
  else if( addend2 <= 0 ){
     throw new IllegalArgumentException("addend2 is <= 0");
  }
  return addend1 + addend2;
}

无论哪种情况，都需要检查以确保调用者正确地使用了您的API。但在第二种情况下，您需要它(隐式地)。如果用户没有读取javadoc，软异常仍然会被抛出，但是:

你不需要记录它。 你不需要测试它(取决于你的攻击性有多强 单元测试策略是)。 您不需要调用者处理三个用例。

最基本的一点是，异常不应该用作返回代码，很大程度上是因为你不仅让你的API变得复杂了，还让调用者的API变得复杂了。

当然，做正确的事情是有代价的。代价是每个人都需要理解他们需要阅读和遵循文档。希望是这样。

因为代码很难阅读，你可能在调试它时遇到麻烦，在很长一段时间后修复错误时，你会引入新的错误，在资源和时间方面更昂贵，如果你正在调试代码，调试器在每次异常发生时停止，这让你很恼火;)

我认为您可以使用异常进行流控制。然而，这种技术也有另一面。创建异常是一件代价高昂的事情，因为它们必须创建堆栈跟踪。因此，如果你想更频繁地使用异常，而不仅仅是发出异常情况的信号，你必须确保构建堆栈跟踪不会对你的性能产生负面影响。

减少创建异常成本的最佳方法是重写fillInStackTrace()方法，如下所示:

public Throwable fillInStackTrace() { return this; }

这样的异常不会填充堆栈跟踪。

除了上述原因之外，不使用异常进行流控制的另一个原因是它会使调试过程变得非常复杂。

例如，当我试图在VS中追踪一个错误时，我通常会打开“中断所有异常”。如果您正在使用异常进行流控制，那么我将定期在调试器中中断，并将不得不继续忽略这些非异常异常，直到我得到真正的问题。这很可能会让人发疯!!

但是你并不总是知道在你调用的方法中发生了什么。您将无法确切地知道异常抛出的位置。不需要更详细地检查异常对象....

您是否曾经尝试调试一个在正常操作过程中每秒引发5个异常的程序?

我有。

该程序相当复杂(它是一个分布式计算服务器)，在程序的一侧稍作修改，就可能很容易破坏完全不同的地方的某些东西。

我希望我可以启动程序，然后等待异常发生，但是在正常的操作过程中，在启动过程中大约有200个异常

我的观点是:如果你在正常情况下使用异常，你如何定位异常情况?

当然，还有其他强有力的理由不要过多使用异常，特别是在性能方面