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

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

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

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

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

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

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

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

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

为什么“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，但因为您使用了最广泛的异常捕获，您的代码可能有其他基本缺陷，将试图运行到完成，浪费带宽，处理时间，磨损您的设备，耗尽内存，收集垃圾数据等。

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

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

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

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

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

>>> 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。我希望这不是你想要的。