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语句。

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

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

有一些通用的机制，语言可以允许一个方法退出而不返回值，并unwind到下一个“catch”块:

Have the method examine the stack frame to determine the call site, and use the metadata for the call site to find either information about a try block within the calling method, or the location where the calling method stored the address of its caller; in the latter situation, examine metadata for the caller's caller to determine in the same fashion as the immediate caller, repeating until one finds a try block or the stack is empty. This approach adds very little overhead to the no-exception case (it does preclude some optimizations) but is expensive when an exception occurs. Have the method return a "hidden" flag which distinguishes a normal return from an exception, and have the caller check that flag and branch to an "exception" routine if it's set. This routine adds 1-2 instructions to the no-exception case, but relatively little overhead when an exception occurs. Have the caller place exception-handling information or code at a fixed address relative to the stacked return address. For example, with the ARM, instead of using the instruction "BL subroutine", one could use the sequence: adr lr,next_instr b subroutine b handle_exception next_instr:

要正常退出，子例程只需执行bx lr或pop {pc};在异常退出的情况下，子例程将在执行返回之前从LR中减去4，或者使用sub LR，#4,pc(取决于ARM的变化，执行模式等)。如果调用者没有被设计为适应它，这种方法将会非常严重地故障。

A language or framework which uses checked exceptions might benefit from having those handled with a mechanism like #2 or #3 above, while unchecked exceptions are handled using #1. Although the implementation of checked exceptions in Java is rather nuisancesome, they would not be a bad concept if there were a means by which a call site could say, essentially, "This method is declared as throwing XX, but I don't expect it ever to do so; if it does, rethrow as an "unchecked" exception. In a framework where checked exceptions were handled in such fashion, they could be an effective means of flow control for things like parsing methods which in some contexts may have a high likelihood of failure, but where failure should return fundamentally different information than success. I'm unaware of any frameworks that use such a pattern, however. Instead, the more common pattern is to use the first approach above (minimal cost for the no-exception case, but high cost when exceptions are thrown) for all exceptions.

我不认为使用异常来进行流控制有什么错。异常有点类似于延续，在静态类型语言中，异常比延续更强大，所以，如果你需要延续，但你的语言没有它们，你可以使用异常来实现它们。

好吧，实际上，如果你需要延续，而你的语言没有，你选择了错误的语言，你应该使用另一种语言。但有时你别无选择:客户端web编程就是最好的例子——没有办法绕过JavaScript。

An example: Microsoft Volta is a project to allow writing web applications in straight-forward .NET, and let the framework take care of figuring out which bits need to run where. One consequence of this is that Volta needs to be able to compile CIL to JavaScript, so that you can run code on the client. However, there is a problem: .NET has multithreading, JavaScript doesn't. So, Volta implements continuations in JavaScript using JavaScript Exceptions, then implements .NET Threads using those continuations. That way, Volta applications that use threads can be compiled to run in an unmodified browser – no Silverlight needed.

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

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

public Throwable fillInStackTrace() { return this; }

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