4. 理解WTForms并灵活改造她

4.1 重写WTForms

优化1

之前的代码,修改完成之后,已经修复了之前的缺陷,但是这样爆出了两个问题: 1.代码太啰嗦了,每个试图函数里,都需要这么写 2.ClientTypeError只是代表客户端类型异常,其他的参数校验不通过也抛出这个异常的话不合适

为了解决上面的问题,我们需要重写wtforms

思路

继承原有的wtforms,重写validate_for_api,修改wtforms为抛出异常 定义一个自定义BaseForm,让其他的Form来继承 app\validators\base.py

from wtforms import Form
from app.libs.erro_code import ParameterException

class BaseForm(Form):
    def __init__(self, data):
        super(BaseForm, self).__init__(data=data)   # 调用父类构造函数

    def validate_for_api(self):
        valid = super(BaseForm, self).validate()  # 调用父类的构造方法 # 验证是否通过
        if not valid:   # 没通过
            # 所有异常类信息在form errors 中 
            raise ParameterException(msg=self.errors) #  抛出异常  # 公共的自定义异常类

定义公共异常类

app\libs\erro_code.py

以后我们的试图函数就可以这样编写

优化2

目前我们每次都需要从request中取出json信息再传入到Form对象中,优化的思路是,直接传入request,在BaseForm中取出json app\validators\base.py

优化3

每次都需要实例化Form对象,再调用validate_for_api()方法,我们可以让validate_for_api方法返回一个self对象,这样就只需要一行代码就可以解决了 app\validators\base.py

优化4

操作成功也需要返回json结构,且结构应该和异常的时候一样,所以我们可以定义一个Success继承APIException app\libs\erro_code.py

优化后视图函数 app\api\v1\client.py

我们可以接受定义时候的复杂,但是不能够接受调用的时候复杂

定义是一次性的,但是调用是多次的,如果调用太过于复杂,会使得我们的 代码太过于臃肿

4.2 全局异常处理

当系统抛出不是我们自己定义的APIException的时候,返回的结果仍然会变成一个HTML文本。

我们在写代码的过程中,有那么类型的异常: 1.已知异常:我们可以预知的。如枚举转换的时候抛出的异常,这时候我们就会提前使用try-except进行处理。也可以抛出APIException 2.未知异常:完全没有预料到的。会由框架抛出的内置异常

我们可以使用flask给我们提供的处理全局异常的装饰器,采用AOP的设计思想,捕捉所有类型的异常。

Last updated

Was this helpful?