为什么“except: pass”是一种糟糕的编程实践? 这为什么不好呢? 试一试: 某物 除了: 通过

这将捕获所有可能的异常，包括GeneratorExit、KeyboardInterrupt和SystemExit——这些异常可能是您不打算捕获的。这和捕获BaseException是一样的。

try:
    something
except BaseException:
    pass

旧版本的文档说:

由于Python中的每个错误都会引发异常，使用except:可以使许多编程错误看起来像运行时问题，从而阻碍调试过程。

Python异常层次结构

如果您捕获了一个父异常类，那么您也捕获了它们的所有子类。只捕获准备处理的异常要优雅得多。

下面是Python 3的异常层次结构——你真的想把它们都捕捉到吗?：

BaseException
 +-- SystemExit
 +-- KeyboardInterrupt
 +-- GeneratorExit
 +-- Exception
      +-- StopIteration
      +-- StopAsyncIteration
      +-- ArithmeticError
      |    +-- FloatingPointError
      |    +-- OverflowError
      |    +-- ZeroDivisionError
      +-- AssertionError
      +-- AttributeError
      +-- BufferError
      +-- EOFError
      +-- ImportError
           +-- ModuleNotFoundError
      +-- LookupError
      |    +-- IndexError
      |    +-- KeyError
      +-- MemoryError
      +-- NameError
      |    +-- UnboundLocalError
      +-- OSError
      |    +-- BlockingIOError
      |    +-- ChildProcessError
      |    +-- ConnectionError
      |    |    +-- BrokenPipeError
      |    |    +-- ConnectionAbortedError
      |    |    +-- ConnectionRefusedError
      |    |    +-- ConnectionResetError
      |    +-- FileExistsError
      |    +-- FileNotFoundError
      |    +-- InterruptedError
      |    +-- IsADirectoryError
      |    +-- NotADirectoryError
      |    +-- PermissionError
      |    +-- ProcessLookupError
      |    +-- TimeoutError
      +-- ReferenceError
      +-- RuntimeError
      |    +-- NotImplementedError
      |    +-- RecursionError
      +-- SyntaxError
      |    +-- IndentationError
      |         +-- TabError
      +-- SystemError
      +-- TypeError
      +-- ValueError
      |    +-- UnicodeError
      |         +-- UnicodeDecodeError
      |         +-- UnicodeEncodeError
      |         +-- UnicodeTranslateError
      +-- Warning
           +-- DeprecationWarning
           +-- PendingDeprecationWarning
           +-- RuntimeWarning
           +-- SyntaxWarning
           +-- UserWarning
           +-- FutureWarning
           +-- ImportWarning
           +-- UnicodeWarning
           +-- BytesWarning
           +-- ResourceWarning

不要这样做

如果你使用这种形式的异常处理:

try:
    something
except: # don't just do a bare except!
    pass

然后你就不能用Ctrl-C来中断你的something块了。您的程序将忽略try代码块中所有可能的异常。

下面是另一个同样有不良行为的例子:

except BaseException as e: # don't do this either - same as bare!
    logging.info(e)

相反，尝试只捕获您知道正在寻找的特定异常。例如，如果你知道你可能会在一个转换中得到一个值错误:

try:
    foo = operation_that_includes_int(foo)
except ValueError as e:
    if fatal_condition(): # You can raise the exception if it's bad,
        logging.info(e)   # but if it's fatal every time,
        raise             # you probably should just not catch it.
    else:                 # Only catch exceptions you are prepared to handle.
        foo = 0           # Here we simply assign foo to 0 and continue. 

用另一个例子进一步解释

您可能会这样做，因为您已经进行了web抓取并得到了一个UnicodeError，但因为您使用了最广泛的异常捕获，您的代码可能有其他基本缺陷，将试图运行到完成，浪费带宽，处理时间，磨损您的设备，耗尽内存，收集垃圾数据等。

如果其他人要求你完成，这样他们就可以依赖你的代码，我理解那种被迫处理所有事情的感觉。但如果你愿意在开发过程中遭遇失败，你就有机会纠正那些偶尔出现的问题，但这将是代价高昂的长期错误。

有了更精确的错误处理，代码就会更加健壮。

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

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

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

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块是对复杂对象层次结构的数百行调用，并且本身是在大型程序的调用树中间调用的。当程序出问题时，你从哪里开始寻找?

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

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

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

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

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'),)

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

简单地说，如果抛出异常或错误，就说明出了问题。这可能不是什么非常错误的事情，但是仅仅为了使用goto语句而创建、抛出和捕获错误和异常并不是一个好主意，而且很少这样做。99%的情况下，都是某个地方出了问题。

问题需要处理。就像在生活中一样，在编程中，如果你把问题放在一边，试着忽略它们，很多时候它们不会自己消失;相反，它们变得越来越大，越来越多。为了防止一个问题在你身上滋生，并在将来再次出现，你要么1)消除它，然后清理混乱，要么2)控制它，然后清理混乱。

忽略异常和错误并让它们保持原样是体验内存泄漏、未完成的数据库连接、不必要的文件权限锁定等的好方法。

在极少数情况下，这个问题是如此微不足道，微不足道，而且——除了需要尝试……Catch block - self-contained，这样就真的没有什么乱七八糟的东西需要清理了。只有在这些情况下，这种最佳实践并不一定适用。根据我的经验，这通常意味着无论代码在做什么，基本上都是微不足道的，可以忽略的，而像重试尝试或特殊消息这样的事情既不值得复杂，也不值得暂停线程。

在我的公司，规则是几乎总是在catch块中做一些事情，如果你什么都不做，那么你必须总是放置一个注释，并给出一个很好的理由。当有事情要做的时候，你绝对不能错过或留下一个空的catch块。