文章目录

快速上手Django(八) -Django之统一异常、Response处理
- 一、统一Response处理
- 二、统一异常处理
- - 1. 需求背景
  - 2. Django、drf统一异常处理
  - 3. Django、drf异常处理基础
  - 4. 纯django场景下
  - 5. 【重要】使用drf场景下，实现思路
  - - 编写自定义异常处理方法
    - 在settings/dev.py文件中添加自定义异常处理模块
- 三、工作常用总结
- - 自定义 serializers.ValidationError 的错误返回
- 四、参考

快速上手Django(八) -Django之统一异常、Response处理

一、统一Response处理

参考本人文章：Django 基础（3）-Django响应：rest_framework的Response、关于HttpResponse

思路：
不推荐使用HttpResponse，推荐自定义类继承rest_framework 的 Response, 该Response继承了django原生的HttpResponse，来实现定制化需求。

直接自定义一个 MyJsonResponse 即可，我们在view中，直接return 这个类即可。

class MyJsonResponse(Response):
    def __init__(self, code=None, msg: Union[str, dict] = 'success',
                 data=None, status=None, template_name=None, headers=None,
                 exception=False, content_type=None, **kwargs):
        super().__init__(None, status=status)

        if isinstance(data, Serializer):
            msg = (
                'You passed a Serializer instance as data, but '
                'probably meant to pass serialized `.data` or '
                '`.error`. representation.'
            )
            raise AssertionError(msg)

        # 改变错误提示格式
        if isinstance(msg, dict):
            for k, v in msg.items():
                for i in v:
                    msg = "%s:%s" % (k, i)

        # 自定义返回格式
        if code is None:
            code = 2000
        self.data = {'code': code, 'msg': msg, 'data': data}
        self.data.update(kwargs)
        self.template_name = template_name
        self.exception = exception
        self.content_type = content_type

        if headers:
            for name, value in headers.items():
                self[name] = value

二、统一异常处理

Django 统一异常处理
参考URL: https://cloud.tencent.com/developer/article/1912568

1. 需求背景

在项目中统一异常处理，可以防止代码中有未捕获的异常出现。

我们想让异常结果也显示为统一的返回结果对象，并且统一处理系统的异常信息，那么需要统一异常处理。

统一规范，方便前后端进行错误统一处理。同时可以更好的区分是因为网络异常，还是后端异常。

后端封装异常的好处是，如果后端异常HTTP RESP CODE是200，代表请求正确打到后端并取得了响应，如果不封装，那么如果出了异常，无法通过HTTP返回码正确区分。

当然也有人不喜欢这种后端异常都是 HTTP RESP CODE是200。其实这里还有一个非常重要的作用，就是一些异常我们要捕获出来，不要暴露给前端。如果不喜欢的所有后端异常都是 HTTP RESP CODE是200，这块全局处理，你也可以配置响应的 HTTP RESP CODE是 500，但是这块统一处理了，我们给前端返回的格式就统一了，这个点比较好！

这样，我们给前端返回的错误信息，就可以根据情况展示到界面上了，可以和前端沟通这种特定格式返回才可以展示到界面上~

2. Django、drf统一异常处理

Django与DRF结合的全局异常处理方案详解
参考URL: jb51.net/article/238484.htm
Django RestFramework 全局异常处理详解
参考URL: https://www.easck.com/cos/2022/0228/909945.shtml

3. Django、drf异常处理基础

Django 和 DRF(django rest framawork) 的结合在 python 后台中经常出现的组合。对于异常的全局处理，我们系统能有一个统一的解决方案，在开发环境能看到比较全的异常堆栈，而在生产环境能更好的给用户一个友好的提示。

如果没有 DRF，我们只需要在 Django 中加一个中间件就可以解决全局异常的处理问题，但是 DRF 会帮我们处理一些异常并自动返回到客户端，因此我们要协调两者的异常处理策略。

DRF 的异常都是继承自 APIException 这个类的，并且 DRF 跑出的异常会被 exception_handler 这个异常处理函数拦截（这个函数的位置在 /python3.7/site-packages/rest_framework/views.py中）

DRF 通过exception_handler 这个函数的文档签名我们知道，DRF 会处理所有继承自 APIException 的异常类，并且还会额外的处理 Django 内置的 Http404 和 PermissionDenied 异常，并将这些异常的处理结果返回到前端。

REST framework定义的异常：

APIException 所有异常的父类

APIException中默认的是 500状态码

ParseError 解析错误
AuthenticationFailed 认证失败
NotAuthenticated 尚未认证
PermissionDenied 权限决绝
NotFound 未找到
MethodNotAllowed 请求方式不支持
NotAcceptable 要获取的数据格式不支持
Throttled 超过限流次数
ValidationError 校验失败
可以看到有些继承APIException 的异常类，覆写了 https状态码，如下

class ValidationError(APIException):
    status_code = status.HTTP_400_BAD_REQUEST

也就是说，很多的没有在上面列出来的异常，就需要我们在自定义异常中自己处理了

如果不再这些处理范围之内，函数会返回 None，这时候会给 Django 抛出一个 500 的服务器错误异常。

Django 在 web 开发中往往会和 DRF 进行结合使用，DRF 有这自己的一套异常处理机制，我们可以对 DRF 中抛出的异常进行全局拦截，比如返回统一的 json 格式以便于前台进行处理。
但是我们同时在 Django 中使用后台 admin 管理数据的同时，不希望修改原有的异常返回。因此我们需要同时配置 Django 和 DRF 的全局异常来适应我们的需求。

4. 纯django场景下

整体思路：

在 Django 项目中可以自定义中间件类继承 django.middleware.common 下的 MiddlewareMixin 中间件类, 覆写process_exception函数。
setting.py 的MiddleWares中添加自定义的MiddleWare

在这里插入图片描述

process_exception(self, request, exception) 函数有两个参数，exception 是视图函数异常产生的 Exception 对象
process_exception 函数的执行顺序是按照 settings.py 中设置的中间件的顺序的倒序执行。（ 如果注册的多个中间件类中包含process_exception函数的时候，调用的顺序跟注册的顺序是相反的）
process_exception 函数只在视图函数中出现异常的时候才执行，它返回的值可以是 None，也可以是一个 HttpResponse 对象
如果返回 None，则继续由下一个中间件的 process_exception 方法来处理异常

5. 【重要】使用drf场景下，实现思路

第一步，自定义自己的异常处理函数
第二步，对 DRF 拦截的异常进行处理
第三步，将其他异常抛给 Django 处理

但是，感觉第三步，不是很需要，drf中定义我们自己业务异常处理，已经满足足够多的业务场景。

因此，这里我选择第一、二步骤！同时，结合自定义的异常和状态码枚举类，来统一和规范异常返回信息。

编写自定义异常处理方法

在utils目录下创建exceptions.py文件，并编写自定义异常处理方法

from django.db import DatabaseError
from rest_framework.response import Response
from rest_framework.views import exception_handler
from rest_framework import status
from redis import RedisError
import logging
log = logging.getLogger("django")

def custom_exception_handler(exc, context):
    """
    自定义异常处理
    :param exc: 本次请求发生的异常信息
    :param context: 本次请求发送异常的执行上下文[ 本次请求的request对象，异常发送的时间，行号等...]
    :return: Response响应对象
    """
    response = exception_handler(exc, context)

    if response is None:
        """当response结果为None时，则当前程序运行的结果有2种可能： 
          1. 程序真的没有报错！
          2. 程序报错了，但是drf框架不识别!
        """
        view = context["view"]
        if isinstance(exc, DatabaseError) or isinstance(exc, RedisError):
            """数据库异常"""
            log.error('[%s] %s' % (view, exc))
            return Response("系统内部存储错误！",  status=status.HTTP_507_INSUFFICIENT_STORAGE)

    return response

参数为 exc、context，exc 为错误异常对象实例
context[‘view’] ：视图类的对象
context[‘request’]：当前请求的对象
我们可以利用这些属性来生成日志，例如：

'ip地址为：%s的用户，访问：%s 视图类，报错了，请求地址是：%s'%(request.META.get('REMOTE_ADDR'),str(view),request.path)

在settings/dev.py文件中添加自定义异常处理模块

DRF 支持单独配置异常处理函数，因此第一步现在 setting 中指定自定义的异常处理函数的位置：

REST_FRAMEWORK = {
    # 异常处理
    'EXCEPTION_HANDLER': 'myxxx.utils.exceptions.custom_exception_handler',
}

三、工作常用总结

自定义 serializers.ValidationError 的错误返回

重写drf的ValidationError, 改变抛出异常的状态码
参考URL: https://blog.csdn.net/Waller_/article/details/108713156

在使用DRF进行反序列过程中，总是需要校验字段，然后返回错误结果。

ValidationError 中默认的状态码是 400

这个章节，推荐查看原文，代码很完整，完善！

四、参考

Django 和 DRF(Django Rest Framework) 下的全局异常处理
参考URL: https://blog.csdn.net/crown_0726/article/details/120792204
Django 统一异常处理
参考URL: https://cloud.tencent.com/developer/article/1912568