第一个原因已经说过了——它隐藏了你没有预料到的错误。

(#2)——它使你的代码难以被其他人阅读和理解。如果你捕捉FileNotFoundException当你试图读取一个文件，那么它是相当明显的另一个开发人员'catch'块应该有什么功能。如果您没有指定异常，那么您需要额外的注释来解释该块应该做什么。

(#3) -它演示了惰性编程。如果您使用通用的try/catch，则表明您不了解程序中可能的运行时错误，或者您不知道Python中可能存在哪些异常。捕捉特定的错误表明您了解程序和Python抛出的错误范围。这更有可能使其他开发人员和代码审查人员信任您的工作。

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

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

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

except:pass构造本质上是在运行try:块中包含的代码时，使出现的任何和所有异常条件保持沉默。

这种糟糕的做法是因为它通常不是你真正想要的。更常见的情况是，出现一些特定的情况，你想要保持沉默，除了:pass是一个太生硬的工具。它将完成工作，但它也会掩盖其他错误条件，您可能没有预料到，但可能非常希望以其他方式处理。

What makes this particularly important in Python is that by the idioms of this language, exceptions are not necessarily errors. They're often used this way, of course, just as in most languages. But Python in particular has occasionally used them to implement an alternative exit path from some code tasks which isn't really part of the normal running case, but is still known to come up from time to time and may even be expected in most cases. SystemExit has already been mentioned as an old example, but the most common example nowadays may be StopIteration. Using exceptions this way caused a lot of controversy, especially when iterators and generators were first introduced to Python, but eventually the idea prevailed.

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

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只会让你的程序处于未知状态，在这种状态下它会造成更多的损害。

我个人更喜欢这个解决方案:

except ValueError as error:
                print(error.args)
                pass

错误。Args给了我一个简单的代码行，它不会太分散人的注意力，但确实有助于代码审查，特别是如果错误有不同的原因，比如

(ValueError('year 0 is out of range'),)
(ValueError('month must be in 1..12'),)
(ValueError('day is out of range for month'),)

当研究熊猫的时间周期时。

执行你的伪代码甚至不会给出任何错误:

try:
    something
except:
    pass

就好像它是一段完全有效的代码，而不是抛出NameError。我希望这不是你想要的。