这是Python之禅系列的一部分，专注于第十条和第十一条原则：静默错误（或不静默错误）。处理“异常情况”是编程中争论最多的问题之一。这可能是因为风险很高：处理不当的错误值甚至会导致庞大的系统崩溃。由于“异常”本质上是测试不足的，但发生的频率令人不快，因此正确处理它们通常可以将噩梦般的系统与“正常工作”的系统区分开来。从Java的checkedexception，到Erlang的故障隔离，再到Haskell的Maybe，不同的语言对于错误处理的态度是完全不同的。这两篇PythonZenofPython就是Python对这个话题的沉思。错误不应该悄无声息地过去......在TimPeters的眼中闪过Python之禅之前，在维基百科被普遍称为“Wiki”之前，第一个维基网站C2已经存在，这是编程指南的宝库。这些原则大部分来自Smalltalk编程社区。Smalltalk思想影响了许多面向对象的语言，包括Python。C2wiki定义了武士原则：“胜利归来，或不归来。”在Python术语中，它鼓励放弃sentinel值，例如返回None或-1表示任务无法完成，但使用抛出异常的方式。None是无声的：它看起来像一个值，可以放在一个变量中传递。有时，它甚至是一个有效的返回值。这里的原则是，如果一个函数不能履行它的契约，它应该“高调地失败”：抛出一个异常。引发的异常似乎从来都不是可能的值。它将跳过returned_value=call_to_function(parameter)行并向上调用堆栈，可能会使程序崩溃。崩溃的调试很简单：有一个堆栈跟踪指示问题以及调用堆栈。崩溃可能意味着不满足程序的必要条件，需要人为干预。这可能意味着程序的逻辑有问题。在任何一种情况下，一个引人注目的失败都比一个隐藏的、“缺失”的价值要好。使用None感染程序的有效负载，直到它在某处使用，并且您可能已经知道，错误消息将显示“None无法拆分”。UnlessexplicitlysilencedUnlessexplicitlysilenced有时需要显式捕获异常。我们可能预见到文件中的某些行格式不正确，并希望以特殊方式处理它们，也许将它们放入“需要人性化外观的行”文件中，而不是使整个程序崩溃。Python允许我们使用except来捕获异常。这意味着可以明确地消除错误。这种清晰度意味着except行在代码审查中是可见的。质疑为什么异常应该被明确地忽略并从这里恢复是有道理的。问问自己是否捕获了太多或太少的异常也是有意义的。因为这些都是显式的，所以有人可以阅读代码并了解哪些异常是可恢复的。
