关于异常的设计

[Francis200214]

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

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

...

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

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

[stick-i]

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

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

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

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

---

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

[Francis200214]

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

[Francis200214]

@stick-i

[stick-i]

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

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

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

应该是这样？

[Francis200214]

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

[stick-i]

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

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

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

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

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

[Francis200214]

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

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

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

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

我看你目前的设计也是如此，如下：

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

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

[stick-i]

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

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

[Francis200214]

好的