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

raise error_codes.UNABLE_TO_UPVOTE
raise error_codes.USER_HAS_BEEN_BANNED
... ...
毫无意外，所有人都很喜欢用这种方式来返回错误码。因为它用起来非常方便辅助论坛，无论调用栈多深，只要你想给用户返回错误码，调用 raiseerror_codes.ANY_THING 就好。
随着时间推移，项目也变得越来越庞大，抛出 APIErrorCode 的地方也越来越多。有一天，我正准备复用一个底层图片处理函数时，突然碰到了一个问题。
我看到了一段让我非常纠结的代码：
# 在某个处理图像的模块内部
# /util/image/processor.py
def process_image(...):
    try:
        image = Image.open(fp)
    except Exception:
        # 说明（非项目原注释）：该异常将会被 Django 的中间件捕获，往前端返回
        # "上传的图片格式有误" 信息
        raise error_codes.INVALID_IMAGE_UPLOADED
    ... ...
process_image 函数会尝试解析一个文件对象，如果该对象不能被作为图片正常打开，就抛出 error_codes.INVALID_IMAGE_UPLOADED（APIErrorCode子类） 异常，从而给调用方返回错误代码 JSON。
让我给你从头理理这段代码。最初编写 process_image 时，我虽然把它放在了 util.image 模块里，但当时调这个函数的地方就只有 “处理用户上传图片的 POST 请求” 而已。为了偷懒，我让函数直接抛出 APIErrorCode 异常来完成了错误处理工作。
再来说当时的问题。那时我需要写一个在后台运行的批处理图片脚本，而它刚好可以复用 process_image 函数所实现的功能。但这时不对劲的事情出现了，如果我想复用该函数，那么：
我必须引入APIErrorCode异常类作为依赖来捕获异常
这就是异常类抽象层级不一致导致的结果。APIErrorCode 异常类的意义，在于表达一种能够直接被终端用户（人）识别并消费的“错误代码”。它在整个项目里，属于最高层的抽象之一。但是出于方便，我们却在底层模块里引入并抛出了它。这打破了 image.processor 模块的抽象一致性，影响了它的可复用性和可维护性。
这类情况属于“模块抛出了高于所属抽象层级的异常”。避免这类错误需要注意以下几点：
在必要的地方进行异常包装与转换
修改后的代码：
# /util/image/processor.py
class ImageOpenError(Exception):
    pass


def process_image(...):
    try:
        image = Image.open(fp)
    except Exception as e:
        raise ImageOpenError(exc=e)
    ... ...

# /app/views.py
def foo_view_function(request):
    try:
        process_image(fp)
    except ImageOpenError:
        raise error_codes.INVALID_IMAGE_UPLOADED
除了应该避免抛出高于当前抽象级别的异常外，我们同样应该避免泄露低于当前抽象级别的异常。
          
<12345>