正如其他人已经多次提到的，最小惊讶原则将禁止您仅为控制流的目的而过度使用异常。另一方面，没有任何规则是100%正确的，总有一些情况下，异常是“合适的工具”——就像goto本身，顺便说一下，它在Java等语言中以break和continue的形式发布，这通常是跳出大量嵌套循环的完美方式，而这种循环并不总是可以避免的。

下面的博文解释了一个相当复杂但也相当有趣的非本地ControlFlowException的用例:

http://blog.jooq.org/2013/04/28/rare-uses-of-a-controlflowexception

它解释了在jOOQ (Java的SQL抽象库)内部，当满足某些“罕见”条件时，如何偶尔使用这种异常来提前中止SQL呈现过程。

这种条件的例子有:

Too many bind values are encountered. Some databases do not support arbitrary numbers of bind values in their SQL statements (SQLite: 999, Ingres 10.1.0: 1024, Sybase ASE 15.5: 2000, SQL Server 2008: 2100). In those cases, jOOQ aborts the SQL rendering phase and re-renders the SQL statement with inlined bind values. Example: // Pseudo-code attaching a "handler" that will // abort query rendering once the maximum number // of bind values was exceeded: context.attachBindValueCounter(); String sql; try { // In most cases, this will succeed: sql = query.render(); } catch (ReRenderWithInlinedVariables e) { sql = query.renderWithInlinedBindValues(); } If we explicitly extracted the bind values from the query AST to count them every time, we'd waste valuable CPU cycles for those 99.9% of the queries that don't suffer from this problem. Some logic is available only indirectly via an API that we want to execute only "partially". The UpdatableRecord.store() method generates an INSERT or UPDATE statement, depending on the Record's internal flags. From the "outside", we don't know what kind of logic is contained in store() (e.g. optimistic locking, event listener handling, etc.) so we don't want to repeat that logic when we store several records in a batch statement, where we'd like to have store() only generate the SQL statement, not actually execute it. Example: // Pseudo-code attaching a "handler" that will // prevent query execution and throw exceptions // instead: context.attachQueryCollector(); // Collect the SQL for every store operation for (int i = 0; i < records.length; i++) { try { records[i].store(); } // The attached handler will result in this // exception being thrown rather than actually // storing records to the database catch (QueryCollectorException e) { // The exception is thrown after the rendered // SQL statement is available queries.add(e.query()); } } If we had externalised the store() logic into "re-usable" API that can be customised to optionally not execute the SQL, we'd be looking into creating a rather hard to maintain, hardly re-usable API.

结论

从本质上讲，我们对这些非本地goto的使用就像[Mason Wheeler][5]在他的回答中所说的那样:

“我刚刚遇到了一种情况，此时我无法正确处理它，因为我没有足够的上下文来处理它，但调用我的例程(或调用堆栈的更上层)应该知道如何处理它。”

controlflowexception的两种用法与它们的替代方法相比都很容易实现，允许我们重用广泛的逻辑，而无需从相关的内部重构它。

但是对于未来的维护者来说，这种感觉还是有点令人惊讶。代码感觉相当微妙，虽然在这种情况下这是正确的选择，但我们总是不喜欢在本地控制流中使用异常，因为在本地控制流中很容易避免使用普通的if - else分支。

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

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

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

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

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

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

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

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

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

我真的不明白你是如何在你引用的代码中控制程序流的。除了ArgumentOutOfRange异常，您将永远不会看到其他异常。(所以你的第二个catch条款永远不会被击中)。您所做的只是使用代价极高的抛出来模拟if语句。

此外，您也没有执行更危险的操作，即仅仅抛出一个异常，以便在其他地方捕获它以执行流控制。你实际上是在处理一个特例。