Skip to content
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

Open
Francis200214 opened this issue Aug 1, 2024 · 9 comments
Open

关于异常的设计 #14

Francis200214 opened this issue Aug 1, 2024 · 9 comments

Comments

@Francis200214
Copy link

异常信息的设计不能只有错误的信息,应该还有一个异常Code码,方便使用者方便快速的查询该Code码所对应的异常出现点的位置,比如:
异常code码:20001
异常信息:身份证号解析错误

异常code码:20002
异常信息:产品名称没有填写

...

不管是使用者公司内部,或者对第三方提供Api的地方,都会有一个异常Code码与对应的错误信息的文档,供本部员工或使用者查看。

这是我的浅显之谈,如果对于框架使用理解错误,请告知,感谢!

@stick-i
Copy link
Owner

stick-i commented Aug 1, 2024

目前项目中的异常场景比较少,常见的异常使用了不同的Exception类来进行区分,比如:

  • SpelArgumentException:参数异常
  • SpelNotSupportedTypeException:不支持的类型异常
  • SpelParserException:表达式解析异常

并且我尽可能的附上了比较完善的异常信息和日志,便于开发者定位问题。

这些内容看起来足以让开发者了解到异常发生的原因,如果日后该框架中有更多异常的出现,并且异常类的通用性较低,异常的原因也较为复杂,那么code码将会派上用场,但在目前看来,它的作用貌似并不大。


换个角度来看,如果你能够通过异常信息来定位到问题所在,那么你还会希望拿着code再去查一遍文档吗?

@Francis200214
Copy link
Author

能够通过异常信息定位到问题的所在当然是最好的了,但是在实际的使用中,使用者可能会用的乱七八糟,可以在框架文档中用户自定义异常message处强调一下这一点

@Francis200214
Copy link
Author

@stick-i

@stick-i
Copy link
Owner

stick-i commented Aug 2, 2024

能够通过异常信息定位到问题的所在当然是最好的了,但是在实际的使用中,使用者可能会用的乱七八糟,可以在框架文档中用户自定义异常message处强调一下这一点

看起来咱两说的异常不是同一个异常:

  • 我前面指的是框架内部抛出的异常信息,是开发者的错误导致的异常
  • 你指的是参数校验失败的时候,抛出给前端的异常,通常是调用者的错误导致的异常

应该是这样?

@Francis200214
Copy link
Author

是的,我想说的就是抛给调用方的异常,对于开发者来说可以通过日志定位到那一行代码,但是对于第三方调用者或者本公司前端来说(本公司还好沟通),一句异常信息可能不太够,往往需要开发者去查询这个接口的日志才能找到。
当然,如果目前还没有使用者反馈这个问题,目前来说是够的。
@stick-i

@stick-i
Copy link
Owner

stick-i commented Aug 2, 2024

是的,我想说的就是抛给调用方的异常,对于开发者来说可以通过日志定位到那一行代码,但是对于第三方调用者或者本公司前端来说(本公司还好沟通),一句异常信息可能不太够,往往需要开发者去查询这个接口的日志才能找到。 当然,如果目前还没有使用者反馈这个问题,目前来说是够的。 @stick-i

我想了一下,如果我们把业务相关的校验转移到了框架上,那确实需要一个code。

当初设计这套框架的时候,是参考了javax.validation的,所以参数什么的基本和那边是一样的。事实上,前者支持业务上的校验,因为可以调用Spring Bean来进行更多操作,而后者是更纯粹的参数校验。所以给前者加个code确实挺好的。

但有一个问题是,这套框架它的校验异常是上报给javax.validation,而并非自己抛出一个异常,而javax.validation的异常信息中并不包含一个int类型的code。要实现起来可能得另辟蹊径了。

或许业务上的校验还是放在Service层更好呢?至少我不会真的在spel里去调用Spring Bean。

@Francis200214
Copy link
Author

我们公司内部的框架设计是下面这个设计:
111

它不仅仅能够对参数进行校验,而且在控制层能够进行业务上的校验,我们使用的方式是下面这个:
image

提供一个工具类,工具类中有很多的判定方法,而第二个也就是后面的参数,就是Code与Message的结合常量。如下:
image

不管是工具类还是参数特定的注解校验,抛出的都是目前跟你一样的异常类,但是我们的异常类是有code码的,最终给客户端的就是有着Code和Message。

我看你目前的设计也是如此,如下:
222

如果可以的话,可以将异常类改造一下。

当然,我们之前的设计是主要考虑控制层的校验,而如果Spel框架主要是对业务层的参数进行校验,那么目前的设计是完全够用的。

@stick-i
Copy link
Owner

stick-i commented Aug 2, 2024

你可能没注意到,我这套东西,它的SpelValidException异常,是对框架使用上的异常,而不是参数校验的异常。

它的参数校验异常信息,是上报到 javax.validation 内的,不是由自己抛出异常。可以把示例项目拉下来体验一下 https://github.com/stick-i/spel-validator-example

@Francis200214
Copy link
Author

好的

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Backlog
Development

No branches or pull requests

2 participants