如果发现异常情况

并非所有异常都是致命的。它们可能是不寻常的，因此也可能是"异常"，但可以实现调用堆栈中更高的点来重试或继续。通过这种方式，异常用于将堆栈和嵌套的一系列函数或方法调用展开到程序中可以实际处理异常原因的点，即使只是清理一些资源、记录错误并像以前一样继续。

您不能总是编写防止异常的代码。举个明显的例子，考虑并发代码。假设我尝试验证i在0和20之间，然后使用i对某个数组进行索引。因此，我检查和i == 12，然后使用它对数组进行索引。不幸的是，在测试和索引操作之间，其他一些线程向i添加了20，所以当它被用作索引时，它已经不在范围内了。

并发性导致了竞争条件，因此针对异常条件进行保证的尝试失败了。虽然可以通过(例如)将每个这样的测试/使用序列包装在一个关键部分(或类似部分)来防止这种情况，但这样做通常是不切实际的——首先，获得正确的代码通常非常困难，其次，即使你确实获得了正确的代码，对执行速度的影响也可能是不可接受的。

异常还将检测到异常条件的代码与对该异常条件做出反应的代码解耦。这就是为什么异常处理在库编写器中如此流行的原因。库中的代码不知道如何正确应对特定的异常情况。对于一个非常琐碎的例子，我们假设它不能从文件中读取。它应该向stderr打印消息、弹出MessageBox还是写入日志？

事实上，它不应该做这些。对于任何给定的程序，至少有两个(可能全部三个)是错误的。因此，它应该抛出一个异常，并让更高级别的代码确定适当的响应方式。对于一个程序来说，记录错误并继续其他工作可能是有意义的，但对于另一个程序，文件可能足够关键，其唯一合理的反应是完全中止执行。

异常非常昂贵，性能也很差-因此，无论何时性能重要，您都希望编写无异常代码(使用"纯C"技术进行错误传播)。

然而，如果性能不是直接的问题，那么异常将允许您开发一个不那么混乱的代码，因为错误处理可以推迟(但随后您将不得不处理非本地控制权转移，这本身可能会令人困惑)。

我使用了大量异常作为一种方法，根据事件处理转移对特定位置的控制。例外情况也可能是将控制权转移到调用函数树中的"标记"位置的方法。当异常发生时，代码可能被认为是一次回溯一个级别，并检查该级别是否有异常活动并执行它

例外情况的真正问题是，你不知道这些情况会在哪里发生。到达异常的代码通常不知道为什么会出现问题，因此快速返回到已知状态是一个很好的操作。举个例子：你在威尼斯，看着地图穿过小路，突然你到达了地图上找不到的地方。从本质上讲，你很困惑，不明白自己在哪里。如果你有ariadne"μιτις"，你可以回到一个已知的点，重新开始，试图到达你想要的地方。

我认为您应该将错误处理仅视为一种控制结构，允许返回到任何级别(通过错误处理例程和错误代码)。