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

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

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

我的经验法则是:

如果您可以做任何事情来从错误中恢复，捕获异常 如果这个错误是很常见的(例如。用户尝试使用错误的密码登录)，使用returnvalues 如果您不能做任何事情来从错误中恢复，那么就让它不被捕获(或者在主捕获器中捕获它，以半优雅地关闭应用程序)

我认为异常的问题纯粹是从语法的角度来看的(我非常确定性能开销是最小的)。我不喜欢到处都是尝试块。

举个例子:

try
{
   DoSomeMethod();  //Can throw Exception1
   DoSomeOtherMethod();  //Can throw Exception1 and Exception2
}
catch(Exception1)
{
   //Okay something messed up, but is it SomeMethod or SomeOtherMethod?
}

. .另一个例子是，当你需要使用工厂将一些东西赋值给一个句柄时，该工厂可能会抛出异常:

Class1 myInstance;
try
{
   myInstance = Class1Factory.Build();
}
catch(SomeException)
{
   // Couldn't instantiate class, do something else..
}
myInstance.BestMethodEver();   // Will throw a compile-time error, saying that myInstance is uninitalized, which it potentially is.. :(

就我个人而言，我认为你应该为罕见的错误条件(内存不足等)保留异常，而使用returnvalues(值类，结构或枚举)来进行错误检查。

希望我正确理解了你的问题:)

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

我有。

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

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

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

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

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

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

public Throwable fillInStackTrace() { return this; }

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

我觉得你的例子没有错。相反，忽略被调用函数抛出的异常是错误的。

在JVM中，抛出异常的代价并不高，只需使用新的xyzException(…)创建异常，因为后者涉及堆栈遍历。因此，如果您预先创建了一些异常，您可以多次抛出它们而无需付出任何代价。当然，这种方式不能将数据与异常一起传递，但我认为无论如何这都是一件糟糕的事情。

标准的回答是，异常是不正常的，应该在特殊情况下使用。

其中一个对我来说很重要的原因是，当我在维护或调试的软件中读取try-catch控制结构时，我试图找出为什么最初的编码器使用异常处理而不是if-else结构。我希望能找到一个好的答案。

请记住，您不仅为计算机编写代码，还为其他编码员编写代码。有一个与异常处理程序相关联的语义，您不能仅仅因为机器不介意就将其丢弃。

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

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

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

很多答案的第一反应是:

你是在为程序员和最小惊讶原则写东西

当然!但如果只是一直不是更清楚。

这并不令人惊讶，例如:divide (1/x) catch (divisionByZero)对我(Conrad和其他人)来说比任何if都更清楚。事实上，这种编程是不被期待的，纯粹是传统的，实际上，仍然是相关的。也许在我的例子中，if会更清楚。

但是在这个问题上，DivisionByZero和FileNotFound比if更清楚。

当然，如果它的性能较差，需要无数的每秒时间，你当然应该避免它，但我仍然没有读到任何好的理由来避免整体设计。

就最小惊讶原则而言:这里存在循环推理的危险:假设整个社区使用了糟糕的设计，那么这种设计将成为预期!因此，这个原则不能是一个圣杯，应该仔细考虑。

对于正常情况的例外，你如何定位异常情况?

在许多反应中，像这样的东西闪耀着光芒。抓住他们，不是吗?你的方法应该是清晰的，有良好的文档记录，并遵守它的契约。我必须承认，我不明白这个问题。

对所有异常进行调试:都是一样的，只是有时会这样做，因为不使用异常的设计很常见。我的问题是:为什么这么普遍?

让我们假设您有一个做一些计算的方法。它必须验证许多输入参数，然后返回一个大于0的数字。

使用返回值来表示验证错误，这很简单:如果方法返回的数字小于0，则发生错误。如何判断哪个参数无效?

我记得在我学习C语言的时候，很多函数返回的错误代码是这样的:

-1 - x lesser then MinX
-2 - x greater then MaxX
-3 - y lesser then MinY

etc.

它真的比抛出和捕获异常的可读性更差吗?

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

一般来说，在低级别处理异常本身并没有什么问题。异常是一个有效的消息，它提供了一个操作为什么不能执行的很多细节。如果你能接受，你就应该接受。

一般来说，如果你知道有很高的失败概率，你可以检查…你应该去检查一下…即if(obj != null) obj.method()

在你的情况下，我对c#库不够熟悉，不知道date time是否有一种简单的方法来检查时间戳是否越界。如果是，只需调用If (.isvalid(ts)) 否则，您的代码基本上没问题。

所以，归根结底，这取决于哪种方式可以创建更干净的代码……如果防止预期异常的操作比处理异常更复杂;那么你就有我的权限来处理异常，而不是到处创建复杂的守卫。

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

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

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

如果您对控制流使用异常处理程序，那么您就太笼统和懒惰了。正如其他人提到的，如果在处理程序中处理处理，就会发生一些事情，但究竟发生了什么?本质上，如果您将异常用于控制流，则您是在为else语句使用异常。

如果您不知道可能会发生什么状态，那么您可以使用异常处理程序处理意外状态，例如当您必须使用第三方库时，或者当您必须捕获UI中的所有内容以显示良好的错误消息并记录异常时。

但是，如果您知道哪里可能出错，而不使用if语句或其他检查方法，那么您就是懒惰。允许异常处理程序成为您知道可能发生的事情的所有人是懒惰的，它稍后会回来困扰您，因为您将试图根据可能错误的假设来修复异常处理程序中的情况。

如果您在异常处理程序中放入逻辑以确定究竟发生了什么，那么如果您没有将该逻辑放入try块中，那么您将非常愚蠢。

异常处理程序是最后的手段，当您无法阻止某些事情出错时，或者事情超出了您的控制能力。比如，服务器宕机并超时，而您无法阻止抛出异常。

最后，提前完成所有检查，显示您知道或预期会发生什么，并使其显式化。代码的意图应该清楚。你更愿意读什么?

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

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

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

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

好吧，实际上，如果你需要延续，而你的语言没有，你选择了错误的语言，你应该使用另一种语言。但有时你别无选择:客户端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.

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

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

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

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

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

在异常之前，C语言中有setjmp和longjmp可以用来完成类似的堆栈帧展开。

然后，同样的构造被赋予了一个名称:“Exception”。大多数答案都依赖于这个名字的含义来争论它的用法，声称例外是为了在特殊情况下使用。这从来不是最初longjmp的意图。只是在某些情况下，您需要在许多堆栈帧之间中断控制流。

异常稍微更通用一些，因为您也可以在同一个堆栈框架中使用它们。我认为这与goto的类比是错误的。Gotos是紧密耦合的一对(setjmp和longjmp也是如此)。异常遵循松散耦合的发布/订阅，这要干净得多!因此，在相同的堆栈框架中使用它们与使用gotos几乎不是一回事。

混淆的第三个来源与它们是被检查的异常还是未检查的异常有关。当然，在控制流和许多其他事情上使用未检查异常似乎特别糟糕。

然而，受控异常对于控制流来说是很好的，一旦你克服了所有维多利亚式的困扰，并生活了一点。

我最喜欢的用法是在一长段代码中使用throw new Success()序列，它不断尝试一件事，直到找到它要找的东西。每一件事——每一段逻辑——都可能有任意的嵌套，因此break也会像任何类型的条件测试一样出现。如果-否则模式是脆弱的。如果我编辑了一个else，或者以其他方式弄乱了语法，那么就有一个毛茸茸的bug。

使用throw new Success()线性化代码流。我使用本地定义的成功类(当然是勾选的)，这样如果我忘记捕获它，代码将无法编译。我没有捕捉到另一种方法的成功。

有时我的代码会逐一检查，只有在一切正常的情况下才会成功。在这种情况下，我使用throw new Failure()进行了类似的线性化。

使用单独的函数会破坏划分的自然级别。所以返回解不是最优的。出于认知上的原因，我更喜欢在一个地方放一两页代码。我不相信超精细分割的代码。

除非有一个热点，否则jvm或编译器做什么对我来说不太重要。我不相信编译器有任何根本原因不检测本地抛出和捕获的异常，而只是在机器代码级别上将它们视为非常有效的goto。

至于在控制流的函数之间使用它们——即在常见情况下而不是特殊情况下——我不明白它们为什么会比多次中断、条件测试、返回来遍历三个堆栈帧而不是仅仅恢复堆栈指针的效率更低。

我个人并没有跨堆栈框架使用这种模式，我可以理解它需要复杂的设计才能做到这一点。但适当地使用它应该没问题。

最后，关于令人惊讶的新手程序员，这不是一个令人信服的理由。如果你温和地引导他们练习，他们就会爱上它。我记得c++曾经让C程序员感到惊讶和害怕。

有一些通用的机制，语言可以允许一个方法退出而不返回值，并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.

一个美学原因是:

“尝试”总是伴随着“成功”，而“如果”并不一定伴随着“其他”。

if (PerformCheckSucceeded())
   DoSomething();

使用try/catch，它变得更加冗长。

try
{
   PerformCheckSucceeded();
   DoSomething();
}
catch
{
}

6行代码太多了。

正如其他人已经多次提到的，最小惊讶原则将禁止您仅为控制流的目的而过度使用异常。另一方面，没有任何规则是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分支。

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

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