Question

从理论上讲，可以在脚本中把所有的语句都包装在try中，但这样做不够明智（这样的话，try语句也需要包装在try语句中）。这其实是设计的问题，不在语言本身的范围内，而且实际运用时，就会更明显。以下是一些简要的原则。

·经常会失败的运算一般都应该包装在try语句内。例如，和系统状态衔接的运算（文件开启、套接字调用等）就是try的主要候选者。

·尽管这样，上边的规则有些特例：在简单的脚本中，你会希望这类运算失败时终止你的程序，而不是被捕捉或是被忽略。如果是一个重大的错误，更是如此。Python中的错误会产生有用的出错消息（如果不是崩溃的话），而且这通常就是所期望的最好结果。

·应该在try/finally中实现终止动作，从而保证它们的执行，除非环境管理器作为一个with/as选项可用。这个语句的形式可以执行代码，无论异常是否发生。

·偶尔，把对大型函数的调用包装在单个try语句内，而不是让函数本身零散着放入若干try语句中，这样会更方便。这样的话，函数中的异常就会往上传递到调用周围的try，而你也可以减少函数中的代码量。

你所编写的程序种类可能会影响处理异常的代码的量。例如，服务器一般都必须持久地运行，所以，可能需要try语句捕捉异常并从中恢复。本章所见的进程内的测试程序可能也需要处理异常。不过，较简单的一次性的脚本，通常会完全忽略异常的处理，因为任何步骤的失败都要求关闭脚本。

捕捉太多：避免空except语句

另一个问题是处理器的通用性问题。Python可选择要捕捉哪些异常，有时候必须小心，不要涵盖太广。例如，空except子句会捕捉try代码块中代码执行时所引发的每个异常。

这样很容易写，并且有时候也是我们想要的结果，但是也可能拦截到异常嵌套结构中较高层的try处理器所期待的事件。例如，下列的异常处理器，会捕捉每个到达的异常并使其停止，无论是否有另一个处理器在等待该事件。

也许更糟，这类代码可能会捕捉无关的系统异常。例如，内存错误、一般程序错误、迭代停止、键盘中断以及系统退出，等等，都会在Python中引发异常。这类异常通常是不应该拦截的。

例如，当控制权到达顶层文件末尾时，脚本正常是退出。然而，Python也提供内置sys.exit(statuscode)调用来提前终止。这实际上是引发内置的SystemExit异常来终止程序，使try/finally可以在离开前执行，而程序的特殊类型可拦截该事件^[1]。因此，try带空except时，可能会不知不觉阻止重要的结束，如下面文件所示（exiter.py）：

可能无法预期运算中可能发生的所有的异常种类。使用上一章介绍的内置异常类，在这种特定情况下会有帮助，因为Exception超类不是SystemExit的一个超类：

在其他情况下，这种方案并不比空的except子句好——因为Exception是所有内置异常（除了系统退出事件以外）之上的一个超类，它仍然有潜力捕获程序中其他地方的异常。

最糟的情况是，空except和捕获Exception类也会捕捉一般程序设计错误，但这类错误多数时候都应让其通过的。事实上，这两种技术都会有效关闭Python的错误报告机制，使得代码中的错误难以发现。例如，考虑下面的代码。

在这里代码的编写者假设，对字典做字典运算时，唯一可能发生的错误就是键错误。但是，因为变量名myditctionary拼写错误了（应该是mydictionary），Python会为未定义的变量名的引用引发NameError，但处理器会默默地捕捉并且忽略了这个异常。事件处理器错误填写了字典错误的默认值，导致了程序出错。如果这件事是发生在离读取值的使用很远的地方，就会变成一项很有趣的调试任务！

经验法则是，尽量让处理器具体化：空except子句很方便，但是可能容易出错。例如，上一个例子中，最好是写except KeyError:，意图明确，避免拦截无关的事件。在较简单脚本中，潜在的问题可能不如全部捕获所带来的便利，通常来说，通用化的处理器一般都是麻烦的源头。

[1]一个相关的调用os._exit也会结束程序，但是通过立即终止：跳过清理动作，无法被try/except或try/finally代码块拦截。这通常只用在衍生的子进程中，但这种话题不在本书讨论的范围之内。参考库手册或后续的书籍以获得更多细节。