电子书 当前页面的脚本发生错误 异常处理的三个好习惯 | Python 工匠

问题就藏在这个硕大无比的 try...except 语句块里。假如你把眼睛贴近屏幕，非常仔细的检查这段代码。你会发现在编写函数时电子书 当前页面的脚本发生错误，我犯了一个小错误，我把获取正则匹配串的方法错打成了 obj.grop(1)，少了一个 'u'（ obj.group(1)）。

但正是因为那个过于庞大、含糊的异常捕获，这个由打错方法名导致的原本该被抛出的 AttibuteError 却被吞噬了。从而给我们的 debug 过程增加了不必要的麻烦。

异常捕获的目的，不是去捕获尽可能多的异常。假如我们从一开始就坚持：只做最精准的异常捕获。那么这样的问题就根本不会发生，精准捕获包括：

依照这个原则，我们的样例应该被改成这样：

from requests.exceptions import RequestException


def save_website_title(url, filename):
    try:
        resp = requests.get(url)
    except RequestException as e:
        print(f'save failed: unable to get page content: {e}')
        return False

    # 这段正则操作本身就是不应该抛出异常的，所以我们没必要使用 try 语句块
    # 假如 group 被误打成了 grop 也没关系，程序马上就会通过 AttributeError 来
    # 告诉我们。
    obj = re.search(r'', resp.text)
    if not obj:
        print('save failed: title tag not found in page content')
        return False
    title = obj.group(1)

    try:
        with open(filename, 'w') as fp:
            fp.write(title)
    except IOError as e:
        print(f'save failed: unable to write to file {filename}: {e}')
        return False
    else:
        return True
2. 别让异常破坏抽象一致性
大约四五年前，当时的我正在开发某移动应用的后端 API 项目。如果你也有过开发后端 API 的经验，那么你一定知道，这样的系统都需要制定一套“API 错误码规范”，来为客户端处理调用错误时提供方便。
一个错误码返回大概长这个样子：
// HTTP Status Code: 400
// Content-Type: application/json
{
    "code": "UNABLE_TO_UPVOTE_YOUR_OWN_REPLY",
    "detail": "你不能推荐自己的回复"
}
在制定好错误码规范后，接下来的任务就是如何实现它。当时的项目使用了 Django 框架，而 Django 的错误页面正是使用了异常机制实现的。打个比方，如果你想让一个请求返回 404 状态码，那么只要在该请求处理过程中执行 raiseHttp404 即可。
所以，我们很自然的从 Django 获得了灵感。首先电子书 当前页面的脚本发生错误，我们在项目内定义了错误码异常类： APIErrorCode。然后依据“错误码规范”，写了很多继承该类的错误码。当需要返回错误信息给用户时，只需要做一次 raise 就能搞定。
          
<12345>