异常是每个程序员都避无可避的“好朋友”，在python编程中尤甚。KeyError、 ValueError、 TypeError、NameError时刻出现在我们的日常编程里。异常的出现往往会令人抓狂。
异常处理工作由“捕获”和“抛出”两部分组成。“捕获”指的是使用 try...except 包裹特定语句，妥当的完成错误流程处理。而恰当地使用 raise 主动“抛出”异常，更是优雅代码里必不可少的组成部分。
即使异常令人崩溃，但是我们不得不面对它，既然无可避免，不妨好好“与它相处”。下面我们一起来看2个处理异常的好习惯。
只做最精确的异常捕获
假如你不够了解异常机制，就难免会对它有一种天然恐惧感。你可能会觉得：异常是一种不好的东西，好的程序就应该不出现任何异常或者捕获并处理所有异常，让一切都平平稳稳的运行。而抱着这种想法写出的代码，里面通常会出现大段含糊的异常捕获逻辑。
以一段可执行脚本作为样例：
脚本里的 save_website_title 函数做了好几件事情。它首先通过网络获取网页内容，然后利用正则匹配出标题，最后将标题写在本地文件里。而这里有两个步骤很容易出错：网络请求 与 本地文件操作。所以在代码里，我们用try...except 语句块，将这几个步骤都包裹了起来。
那么，这段看上去简洁易懂的代码，里面藏着什么问题呢？
如果你旁边刚好有一台安装了 Python 的电脑，那么你可以试着跑一遍上面的脚本。你会发现，上面的代码是不能成功执行的。而且你还会发现，无论你如何修改网址和目标文件的值，程序仍然会报错 “save failed: unable to...”。为什么呢？
问题就藏在这个硕大无比的 try...except 语句块里。假如你仔细的检查这段代码，你会发现代码里有一个小错误，获取正则匹配串的方法错打成了 obj.grop(1)，少了一个 'u'( obj.group(1))。
但正是因为那个过于庞大、含糊的异常捕获，这个由打错方法名导致的原本该被抛出的 AttibuteError 却被吞噬了。从而给我们的 debug 过程增加了不必要的麻烦。
异常捕获的目的，不是去捕获尽可能多的异常。假如我们从一开始就坚持：只做最精准的异常捕获。那么这样的问题就根本不会发生，精准捕获包括：
- 永远只捕获那些可能会抛出异常的语句块
- 尽量只捕获精确的异常类型，而不是模糊的 Exception
依照这个原则，上面的样例应该被改成这样：
异常处理不应该喧宾夺主
在前面我们提到异常捕获要精准，但在现实编程中，如果你严格遵循这些流程，那么很有可能会碰上另外一个问题：异常处理逻辑太多，以至于扰乱了代码核心逻辑。具体表现就是，代码里充斥着大量的 try、 except、 raise 语句，让核心逻辑变得难以辨识。
请看下面这段代码：
这是一个处理用户上传头像的视图函数。这个函数内做了三件事情，并且针对每件事都做了异常捕获。如果做某件事时发生了异常，就返回对用户友好的错误提示。
这样的处理流程纵然合理，但是显然代码里的异常处理逻辑有点“喧宾夺主”了。一眼看过去全是代码缩进，很难提炼出代码的核心逻辑。
早在 2.5 版本时，Python 语言就已经提供了对付这类场景的工具：“上下文管理器(context manager)”。上下文管理器是一种配合 with 语句使用的特殊 Python 对象，通过它，可以让异常处理工作变得更方便。
那么，如何利用上下文管理器来改善我们的异常处理流程呢？让我们直接看代码吧。
在上面的代码里，我们定义了一个名为 raise_api_error 的上下文管理器，它在进入上下文时什么也不做。但是在退出上下文时，会判断当前上下文中是否抛出了类型为 self.captures 的异常，如果有，就用 APIErrorCode 异常类替代它。
使用该上下文管理器后，整个函数可以变得更清晰简洁：
总结来说，正视异常也不过分看重异常。
- 只捕获可能会抛出异常的语句，避免含糊的捕获逻辑
- 使用“上下文管理器”可以简化重复的异常处理逻辑
希望这篇文章可以帮你与异常这位老朋友和平相处~~~
