Open Francis200214 opened 1 month ago
目前项目中的异常场景比较少,常见的异常使用了不同的Exception类来进行区分,比如:
并且我尽可能的附上了比较完善的异常信息和日志,便于开发者定位问题。
这些内容看起来足以让开发者了解到异常发生的原因,如果日后该框架中有更多异常的出现,并且异常类的通用性较低,异常的原因也较为复杂,那么code码将会派上用场,但在目前看来,它的作用貌似并不大。
换个角度来看,如果你能够通过异常信息来定位到问题所在,那么你还会希望拿着code再去查一遍文档吗?
能够通过异常信息定位到问题的所在当然是最好的了,但是在实际的使用中,使用者可能会用的乱七八糟,可以在框架文档中用户自定义异常message处强调一下这一点
@stick-i
能够通过异常信息定位到问题的所在当然是最好的了,但是在实际的使用中,使用者可能会用的乱七八糟,可以在框架文档中用户自定义异常message处强调一下这一点
看起来咱两说的异常不是同一个异常:
应该是这样?
是的,我想说的就是抛给调用方的异常,对于开发者来说可以通过日志定位到那一行代码,但是对于第三方调用者或者本公司前端来说(本公司还好沟通),一句异常信息可能不太够,往往需要开发者去查询这个接口的日志才能找到。 当然,如果目前还没有使用者反馈这个问题,目前来说是够的。 @stick-i
是的,我想说的就是抛给调用方的异常,对于开发者来说可以通过日志定位到那一行代码,但是对于第三方调用者或者本公司前端来说(本公司还好沟通),一句异常信息可能不太够,往往需要开发者去查询这个接口的日志才能找到。 当然,如果目前还没有使用者反馈这个问题,目前来说是够的。 @stick-i
我想了一下,如果我们把业务相关的校验转移到了框架上,那确实需要一个code。
当初设计这套框架的时候,是参考了javax.validation的,所以参数什么的基本和那边是一样的。事实上,前者支持业务上的校验,因为可以调用Spring Bean来进行更多操作,而后者是更纯粹的参数校验。所以给前者加个code确实挺好的。
但有一个问题是,这套框架它的校验异常是上报给javax.validation,而并非自己抛出一个异常,而javax.validation的异常信息中并不包含一个int类型的code。要实现起来可能得另辟蹊径了。
或许业务上的校验还是放在Service层更好呢?至少我不会真的在spel里去调用Spring Bean。
我们公司内部的框架设计是下面这个设计:
它不仅仅能够对参数进行校验,而且在控制层能够进行业务上的校验,我们使用的方式是下面这个:
提供一个工具类,工具类中有很多的判定方法,而第二个也就是后面的参数,就是Code与Message的结合常量。如下:
不管是工具类还是参数特定的注解校验,抛出的都是目前跟你一样的异常类,但是我们的异常类是有code码的,最终给客户端的就是有着Code和Message。
我看你目前的设计也是如此,如下:
如果可以的话,可以将异常类改造一下。
当然,我们之前的设计是主要考虑控制层的校验,而如果Spel框架主要是对业务层的参数进行校验,那么目前的设计是完全够用的。
你可能没注意到,我这套东西,它的SpelValidException异常,是对框架使用上的异常,而不是参数校验的异常。
它的参数校验异常信息,是上报到 javax.validation 内的,不是由自己抛出异常。可以把示例项目拉下来体验一下 https://github.com/stick-i/spel-validator-example
好的
异常信息的设计不能只有错误的信息,应该还有一个异常Code码,方便使用者方便快速的查询该Code码所对应的异常出现点的位置,比如: 异常code码:20001 异常信息:身份证号解析错误
异常code码:20002 异常信息:产品名称没有填写
...
不管是使用者公司内部,或者对第三方提供Api的地方,都会有一个异常Code码与对应的错误信息的文档,供本部员工或使用者查看。
这是我的浅显之谈,如果对于框架使用理解错误,请告知,感谢!