对于对于Python异常处理慎用异常处理慎用“except:pass”建议建议
翻译自StackOverflow中一个关于Python异常处理的问答。
问题：为什么问题：为什么“except:pass”是一个不好的编程习惯？是一个不好的编程习惯？
我时常在StackOverflow上看到有人评论关于except: pass的使用，他们都提到这是一个不好的Python编程习惯，应该避免。
可我想知道为什么？有时候我并不在意出现的错误，而是只想让我的程序继续进行下去。就像这样：
try:
something
except:
pass
为什么这么使用except:pass不好？这背后的原因是什么，是不是因为这样我会放掉一些本该被处理的错误？还是这样我会捕
获到所有类型的错误？
最佳回答：最佳回答：
正如你所猜测的那样，这么做的确有两个不好的地方。首先，因为没有指定任何异常类型，所以会捕获到任何类型的错误。其
次，捕获到错误之后只会简单地让它通过而不是采取必要的处理措施。
我接下来的解释或许会有点长，所以将重点总结如下：
1. 不要将任意类型的错误作为捕获对象。必须明确你想要捕获的错误类型，并且写明只捕获它们。
2. 不要试图简单地敷衍错误处理动作。除非这么做是有目的的，但这通常都不太好。
那么接下来让我们更深入一些：
不要将任意异常作为捕获目标不要将任意异常作为捕获目标
当在代码中的某个地方使用异常捕获语句块时，你通常知道这个地方可能会抛出异常，并且你也知道这个地方可能会发生什么
样的问题进而抛出何种异常，一旦异常被抛出，你将捕获到这个异常并使程序回到正轨上来。这就意味着你一定对这种异常有
所准备，并能够在它发生的时候及时采取措施进行处理。
举个例子，你需要用户输入一个数字，并且使用int()函数将用户输入的字符串转换为整数类型，这时候你一定会想到如果输入
的字符串并不是数字，那么就会发生值错误(ValueError)。如果真的发生了错误，那么你可以通过简单的让用户重新输入来让
程序回到正轨，所以捕获值错误以及促使用户重新输入就是一个比较合理的处理策略。再举一个例子，如果你想从一个文件中
读取配置信息，但正巧这个文件不存在。那么因为这是一个配置文件，如果它不存在你会返回一些默认的配置选项，所以这个
文件就不是这么必要了。在这个例子中，捕获文件未找到错误(FileNotFoundError)以及返回默认配置项则是一个比较合适的处
理策略。通过以上两个例子可以看到，我们都是在等待捕获特定的错误，并且针对每种错误都有特定的处理策略。
然而，如果我们在这里捕获所有的异常，那么为特定异常准备的那些处理策略就会因为遇到非正常类型的异常而失效，这将会
使得正常的程序流程中断并且无法恢复。
让我们还是举配置文件的那个例子。正常的处理策略是如果发现文件并不存在，我们将使用默认的配置项，并可能在稍后决定
是否将当前的配置项自动保存为配置文件(这样的话下一次文件就肯定存在了)。现在让我们假定我们捕获到了一个
IsADirectoryError或是PermissionError错误，在这种情况下，我们可能不想让程序继续执行，我们仍然能够使用默认的配置参
数，但是随后我们就不能保存文件了。也有可能用户希望使用自定义的配置项，所以这样的话就不能使用默认配置项了。所以
我们这时候可能需要立即告知用户并停止当前程序。也有可能我们并不想在这么一小块代码中做这么多的事情，而是让应用层
面的部分去关心它，所以我们也可能让这个错误浮到顶层，让顶层的业务逻辑去处理。
在Python 2 idioms document文档中也提到了一个简单的例子：如果在我们的代码中出现了一个简单的拼写错误而导致程序错
误。在这种情况下因为我们捕获所有的异常，所以我们将会捕获到名称错误(NameErrors)以及语法错误(SyntaxErrors)。两者
都是常见的错误，并且两者都是不希望出现在我们最终代码中的。但是因为我们什么异常都逮，当异常发生时我们将无法区分
具体的错误类型并且无法进行调试。
但是也存在这样一些并未预先准备的危险异常，诸如系统错误(SystemError)就很少发生以至于我们根本没有准备；这些异常
通常需要更复杂的处理操作，这些操作通常可能会要求我们停止当前的工作。
在任何情况下，通过局部代码实现对所有异常的处理基本上都是不可能的，所以你应该有针对性的去处理那些经过准备的特定
异常。有些人曾建议至少应该明确指明基本异常(Exception)这样的不包含诸如系统退出(SystemExit)和键盘中断
(KeyboardInterrupt)这样设计用来终止应用程序的异常。但是我想说这样还是不够明确，并且我个人认为只有在一个地方才能
仅仅只捕获Exception或是任何类型的异常，那就是一个单独的，应用程序层面的异常捕获器，并且这个捕获器唯一的任务就
是去捕获任何可能出现的未经准备的漏网异常。这样的话我们仍然能够保留意外发生异常的相关信息作为进一步的代码扩展的
依据(让然如果我们能让程序恢复的话)，这样下一次我们就能够把这个异常在合适的地方显式地指定出来或是指导我们撰写测
试用例以保证错误不再发生(当然了，这一切还是要当我们对特定异常有所准备时，没有准备的异常还是会溜掉)。
在异常处理的逻辑中，不要什么都不做在异常处理的逻辑中，不要什么都不做
资源评论
