我经常在其他Stack Overflow问题上看到关于如何不鼓励使用except: pass的评论。这为什么不好呢?有时我不在乎错误是什么,我只想继续写代码。

try:
    something
except:
    pass

为什么使用except: pass块不好?是什么让它变得糟糕?是我传递了一个错误还是我排除了任何错误?


当前回答

>>> 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!

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

其他回答

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

try:
    something
except:
    pass

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

你至少应该使用except Exception:来避免捕获系统异常,如SystemExit或KeyboardInterrupt。这里是文档链接。

一般来说,您应该显式地定义想要捕获的异常,以避免捕获不想要的异常。您应该知道您忽略了哪些异常。

如果这是糟糕的做法,“通过”就不会是一个选项。 如果你有一个资产,从许多地方接收信息IE一个表单或userInput,它就会派上用场。

variable = False
try:
    if request.form['variable'] == '1':
       variable = True
except:
    pass

In my opinion errors have a reason to appear, that my sound stupid, but thats the way it is. Good programming only raises errors when you have to handle them. Also, as i read some time ago, "the pass-Statement is a Statement that Shows code will be inserted later", so if you want to have an empty except-statement feel free to do so, but for a good program there will be a part missing. because you dont handle the things you should have. Appearing exceptions give you the chance to correct input data or to change your data structure so these exceptions dont occur again (but in most cases (Network-exceptions, General input-exceptions) exceptions indicate that the next parts of the program wont execute well. For example a NetworkException can indicate a broken network-connection and the program cant send/recieve data in the next program steps.

但是只对一个执行块使用pass块是有效的,因为你仍然可以区分不同类型的异常,所以如果你把所有的异常块放在一个中,它就不是空的:

try:
    #code here
except Error1:
    #exception handle1

except Error2:
    #exception handle2
#and so on

可以写成这样:

try:
    #code here
except BaseException as e:
    if isinstance(e, Error1):
        #exception handle1

    elif isinstance(e, Error2):
        #exception handle2

    ...

    else:
        raise

因此,即使是多个带有pass语句的异常块也可能导致代码,其结构处理特殊类型的异常。

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.