Bare-Except 不受欢迎的任何原因答案

【问题标题】：Any Reason why Bare-Except's are Frowned UponBare-Except 不受欢迎的任何原因
【发布时间】：2015-07-29 11:19:51
【问题描述】：

以一种有限的方式，我想知道为什么在 Python 中使用裸例外如此不受欢迎。

如果我有一个完整的程序正在运行并且我执行以下操作，我就会明白：

import sys
from application import program
try:
    program.start()
except:
    print >> sys.stderr, "It didn't work"

我隐瞒了重要信息，没有得到真正的输出。但是让我们考虑一下我正在为配置设置执行 IO 操作，并且如果配置不存在或损坏，我有一组模板数据可供使用：

import os
from config import load_data
from template import save_data

dir = os.path.expanduser('~')
path = os.path.join(dir, 'config.txt')
try:
    load_data(path)
except:
    save_data(path)

我想在这种情况下，最好构建一个自定义异常来捕获操作，以便为阅读代码的人提供更多信息？

【问题讨论】：

标签： python python-2.7

【解决方案1】：

您的示例是一个精彩的示例，说明了为什么这是一个坏主意。您的程序不是“如果数据不存在或损坏，则用模板覆盖它”。您的程序是“如果出现任何问题，请尝试使用模板覆盖数据”。

例如，如果您在尝试加载数据时执行的代码中有拼写错误，您的程序不会通知您，而是使用模板覆盖您的所有（有效！）数据。这可能是一个相当灾难性的错误，无论是在丢失数据方面，还是在测试用例遗漏的不经常使用的代码路径中出现拼写错误时，您可以多么容易地说服自己这不可能是问题所在。

另一个出错的例子是如果用户决定尝试使用 Ctrl+C 中止程序。你会抓住KeyboardInterrupt 并立即破坏他的所有数据。

【讨论】：

这实际上是一个非常好的捕获，所以在这种情况下，它是否会是： except IOError: save_data(path) except CustomError: save_data(path) except: sys.exit(1)
顺便说一句，我强烈建议不要尝试在太低的级别上进行错误处理；进行某种初始化的例程可能没有足够的知识来了解任何应用程序可能想要使用它来了解错误时应该发生什么，并且几乎可以肯定没有足够的知识来知道这一点sys.exit 是对错误的适当响应。（当然，这个一般原则也有例外，但在您这样做之前，您应该确定您确实属于这些例外之一）

【解决方案2】：

说bare-excepts 是一个坏主意的原因之一是，根据Python 或任何可能的语言，任何强制程序退出的东西都是例外。

例如，来自终端的 Ctrl+C

因此，我们正在寻找导致程序关闭的特定类型的错误，并相应地执行操作。因此，指定要处理的异常类型有助于缩小实际原因并帮助您进行修正

【讨论】：