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

11/28 05:09:02 来源网站:辅助卡盟网

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

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

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

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

  1. 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 错误码规范”,来为客户端处理调用错误时提供方便。

    一个错误码返回大概长这个样子:

    1. // HTTP Status Code: 400

      // Content-Type: application/json

      {

      "code": "UNABLE_TO_UPVOTE_YOUR_OWN_REPLY",

      "detail": "你不能推荐自己的回复"

      }

      在制定好错误码规范后,接下来的任务就是如何实现它。当时的项目使用了 Django 框架,而 Django 的错误页面正是使用了异常机制实现的。打个比方,如果你想让一个请求返回 404 状态码,那么只要在该请求处理过程中执行 raiseHttp404 即可。

      所以,我们很自然的从 Django 获得了灵感。首先电子书 当前页面的脚本发生错误,我们在项目内定义了错误码异常类: APIErrorCode。然后依据“错误码规范”,写了很多继承该类的错误码。当需要返回错误信息给用户时,只需要做一次 raise 就能搞定。

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