-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
关于异常的设计 #14
Comments
目前项目中的异常场景比较少,常见的异常使用了不同的Exception类来进行区分,比如:
并且我尽可能的附上了比较完善的异常信息和日志,便于开发者定位问题。 这些内容看起来足以让开发者了解到异常发生的原因,如果日后该框架中有更多异常的出现,并且异常类的通用性较低,异常的原因也较为复杂,那么code码将会派上用场,但在目前看来,它的作用貌似并不大。 换个角度来看,如果你能够通过异常信息来定位到问题所在,那么你还会希望拿着code再去查一遍文档吗? |
能够通过异常信息定位到问题的所在当然是最好的了,但是在实际的使用中,使用者可能会用的乱七八糟,可以在框架文档中用户自定义异常message处强调一下这一点 |
看起来咱两说的异常不是同一个异常:
应该是这样? |
是的,我想说的就是抛给调用方的异常,对于开发者来说可以通过日志定位到那一行代码,但是对于第三方调用者或者本公司前端来说(本公司还好沟通),一句异常信息可能不太够,往往需要开发者去查询这个接口的日志才能找到。 |
我想了一下,如果我们把业务相关的校验转移到了框架上,那确实需要一个code。 当初设计这套框架的时候,是参考了javax.validation的,所以参数什么的基本和那边是一样的。事实上,前者支持业务上的校验,因为可以调用Spring Bean来进行更多操作,而后者是更纯粹的参数校验。所以给前者加个code确实挺好的。 但有一个问题是,这套框架它的校验异常是上报给javax.validation,而并非自己抛出一个异常,而javax.validation的异常信息中并不包含一个int类型的code。要实现起来可能得另辟蹊径了。 或许业务上的校验还是放在Service层更好呢?至少我不会真的在spel里去调用Spring Bean。 |
你可能没注意到,我这套东西,它的SpelValidException异常,是对框架使用上的异常,而不是参数校验的异常。 它的参数校验异常信息,是上报到 javax.validation 内的,不是由自己抛出异常。可以把示例项目拉下来体验一下 https://github.com/stick-i/spel-validator-example |
好的 |
异常信息的设计不能只有错误的信息,应该还有一个异常Code码,方便使用者方便快速的查询该Code码所对应的异常出现点的位置,比如:
异常code码:20001
异常信息:身份证号解析错误
异常code码:20002
异常信息:产品名称没有填写
...
不管是使用者公司内部,或者对第三方提供Api的地方,都会有一个异常Code码与对应的错误信息的文档,供本部员工或使用者查看。
这是我的浅显之谈,如果对于框架使用理解错误,请告知,感谢!
The text was updated successfully, but these errors were encountered: