我赞成马特·乔纳（Matt Joiner）的回答，但想补充一些观察意见，以使我们清楚地了解，与其他几个因素相比，在预检查条件之间进行选择时，有 4
倍的重要性（被称为LBYL或“请先检查一下”） ”），并且仅处理异常（称为EAFP或“比许可更容易请求宽恕”）。
这些时间是：
- LBYL检查 成功 的时间
- LBYL检查 失败 的时间
- 当异常定时 不 与EAFP抛出
- 当异常时序 是 与EAFP抛出
其他因素是：
- 检查成功/失败或引发异常/未引发案例的典型比率
- 是否存在禁止使用LBYL的比赛条件
最后一点是首先需要解决的问题：如果存在争用条件的可能性，那么您别无选择， 必须 使用异常处理。一个典型的例子是：
if <dir does not exist>: <create dir> # May still fail if another process creates the target dir
由于LBYL并不排除此类情况的例外，因此它没有真正的好处，也没有做出判断的要求：EAFP是唯一可以正确处理比赛条件的方法。
但是，如果没有竞争条件，则两种方法都可能可行。它们提供了不同的权衡：
- 如果没有异常，那么EAFP几乎是免费的
- 但是，如果发生异常，则相对昂贵，因为展开堆栈，创建异常并将其与异常处理子句进行比较涉及大量处理
- 相比之下，LBYL可能会产生较高的固定成本：无论成功与否，始终执行附加检查
然后得出以下决策标准：
- 是否知道这段代码对应用程序的速度至关重要？如果不是，那么不必担心两者中的哪一个更快，而不必担心两者中的哪一个更容易阅读。
- 预检是否比引发和捕获异常的成本贵？如果是，则EAFP总是更快，应该使用。
- 如果答案为“否”，事情就会变得更加有趣。在那种情况下，更快的速度取决于成功或错误情况是否更常见，以及预检查和异常处理的相对速度。明确地回答这个问题需要实际的时序测量。
作为一个粗略的经验法则：
- 如果存在潜在的比赛条件，请使用EAFP
- 如果速度不是很关键，请使用您认为更易于理解的方式
- 如果预检查价格昂贵，请使用EAFP
- 如果您希望操作在大多数时间都能成功*，请使用EAFP
- 如果您期望操作失败超过一半的时间，请使用LBYL
- 如有疑问，请进行测量
*在这种情况下，人们对于“大多数时间”的看法会有所不同。对我来说，如果我希望该操作能成功完成一半以上的时间，那我当然会使用EAFP，直到我有理由怀疑这段代码是实际的性能瓶颈。
