那么，这段代码产生了什么输出呢?

fruits = [ 'apple', 'pear', 'carrot', 'banana' ]

found = False
try:
     for i in range(len(fruit)):
         if fruits[i] == 'apple':
             found = true
except:
     pass

if found:
    print "Found an apple"
else:
    print "No apples in list"

现在，想象一下try-except块是对复杂对象层次结构的数百行调用，并且本身是在大型程序的调用树中间调用的。当程序出问题时，你从哪里开始寻找?

到目前为止提出的所有意见都是有效的。在可能的情况下，您需要指定想要忽略的异常。在可能的情况下，你需要分析导致异常的原因，只忽略你想要忽略的部分，而不是其他部分。如果异常导致应用程序“壮观地崩溃”，那么就这样吧，因为知道意外发生的时间比隐藏问题发生的时间要重要得多。

综上所述，不要将任何编程实践视为至高无上的。这太愚蠢了。总有时间和地点可以执行“忽略所有异常”块。

白痴派拉特的另一个例子是goto运算符的使用。当我还在学校的时候，我们的教授教我们去运算符，只是为了提醒我们永远不能使用它。不要相信人们告诉你xyz永远不应该被使用，也不可能有一个场景它是有用的。总是有的。

通常，您可以将任何错误/异常分为以下三类之一:

Fatal: Not your fault, you cannot prevent them, you cannot recover from them. You should certainly not ignore them and continue, and leave your program in an unknown state. Just let the error terminate your program, there is nothing you can do. Boneheaded: Your own fault, most likely due to an oversight, bug or programming error. You should fix the bug. Again, you should most certainly not ignore and continue. Exogenous: You can expect these errors in exceptional situations, such as file not found or connection terminated. You should explicitly handle these errors, and only these.

在除了:pass之外的所有情况下，pass只会让你的程序处于未知状态，在这种状态下它会造成更多的损害。

因为它还没有被提及，所以使用contextlib.suppress是更好的风格:

with suppress(FileNotFoundError):
    os.remove('somefile.tmp')

在本例中，somefile.tmp在执行此代码块后将不存在，而不会引发任何异常(除了FileNotFoundError，它被抑制)。

我正在构建一个将在数据中心运行的应用程序。它不应该生成任何错误或引发任何异常。我的数据中心有一个网络监控系统，其中包括一个SNMP trap接收器。

try:
    main()
except as e:
    log(str(e))
    send_snmp_trap(str(e))
    raise

但是这个加薪不会有任何效果因为它是和任何可能剩下的堆栈的底部。

顺便说一句，这不是万能的灵丹妙药。有一些例外情况是无法被发现的。SNMP不能保证传输。YMMV。

>>> import this

The Zen of Python, by Tim Peters Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. Now is better than never. Although never is often better than right now. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea -- let's do more of those!

所以，这是我的观点。每当你发现一个错误，你应该做一些事情来处理它，即把它写在日志文件或其他东西。至少，它告诉您曾经有一个错误。