以下是我在博客中描述的最佳实践:

抛出异常以说明软件中的意外情况。 使用返回值进行输入验证。 如果您知道如何处理库抛出的异常，请在尽可能低的级别捕获它们。 如果出现意外异常，请完全放弃当前操作。不要假装你知道如何对付他们。

异常基本上是非本地的goto语句，具有后者的所有结果。在流控制中使用异常违反了最小惊奇原则，使程序难以阅读(请记住，程序首先是为程序员编写的)。

而且，这不是编译器供应商所期望的。他们希望很少抛出异常，并且他们通常让抛出代码非常低效。抛出异常是。net中最昂贵的操作之一。

然而，一些语言(尤其是Python)使用异常作为流控制结构。例如，如果没有其他项，迭代器将引发StopIteration异常。即使是标准的语言结构(比如for)也依赖于此。

你可能会对Common Lisp的条件系统感兴趣，它是对异常的一种概括。因为你可以以一种可控的方式展开堆栈，也可以得到“重启”，这非常方便。

这与其他语言的最佳实践没有太大关系，但它向您展示了在您正在考虑的方向上，使用一些设计思想可以完成什么。

当然，如果您像溜溜球一样在堆栈上上下跳动，仍然存在性能考虑，但这比大多数捕获/抛出异常系统所体现的“哦，糟糕，让我们离开”这种方法要普遍得多。

性能如何?在负载测试一个。net web应用程序时，我们在每个web服务器上模拟了100个用户，直到我们修复了一个常见的异常，这个数字增加到500个用户。

您可以使用锤子的爪来拧螺丝，就像您可以为控制流使用异常一样。这并不意味着这是该特性的预期用途。if语句表示条件，其预期用途是控制流。

如果您以一种意想不到的方式使用特性，同时又选择不使用为此目的而设计的特性，那么将会有相关的成本。在这种情况下，清晰度和性能没有真正的附加价值。与广泛接受的if语句相比，使用异常能给您带来什么?

换句话说:你能做并不意味着你应该做。

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变得复杂了。

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