最近收到这样的问题:
领域服务做业务逻辑校验时应该返回错误码还是抛出业务异常?
这其实不算是领域服务的问题,而是Java异常处理问题。
之前总结过一次如何处理异常
上面的文章基本上就解决异常相关问题了。
这儿再回顾总结一下:
返回错误码
在异常没有出现时,像C语言是如何处理问题的?
在 C 语言中,错误码的返回方式有两种:一种是直接占用函数的返回值,函数正常执行的返回值放到出参中;另一种是将错误码定义为全局变量,在函数执行出错时,函数调用者通过这个全局变量来获取错误码
1 |
|
错误码没有性能问题,但带来了维护性,尤其没有了异常堆栈信息,失去了快速定位问题的能力。
抛异常
在OO世界中,更推荐使用异常方式,显得更OO些
Checked Exception
Spring创始人Rod Johnson列举了检查异常几个问题:
1、太多的代码
开发人员不得不捕捉他们无法处理的检查异常
2、难以读懂的代码
捕捉不能处理的异常并重新抛出,没有执行一点有用的功能,反而会使查找实际做某件事的代码变得更困难
3、异常无休止封装
4、易毁坏的方法签名
一旦这么多调用者使用一个方法,添加一个额外的检查异常到该接口上将需要这么多代码被修改。也些违背OCP原则
5、检查异常对接口不一定管用
接口有很多种实现,有些实现会出现异常,但有些是不会出现异常的,比如存储数据,放在文件会抛IO相关异常,但数据是数据库,刚不是此异常。
Runtime Exception
运行期异常被很多大牛接受推荐,但也有弊病,就是调用方需要知道内部实现细节,了解抛出了些什么异常,需在javadoc中给出明确说明。
当然我们现在可以使用AOP技术,对异常进行兜底处理,以防泄漏到用户层。
性能
当使用异常时,性能得确会下降,尤其调用链路很深时,更加明显。但异常总归是少数情况,不影响正常情况的性能。
但有些系统对性能要求比较高,怎么办?如正常情况是百万QPS,就算出现少许异常情况,对系统可用性也带来不小的影响。
怎么办?退回错误码时代
但从设计角度可改良一下,可以不再简单返回错误码,如可以使用vavr的Either
1 | Either<ExceptionMessage,Result> do(); |
让调用方式来最终确定,当either.isLeft()时,是向上抛异常,还是额外处理。
良好实践
使用检查异常还是运行时异常是个见解问题,不管如何选择,只要团队达成共识,统一规范就可以。
良好的异常,不管是对开发人员,还是运维,用户都应该有全面友好的提示信息
对开发人员,在异常中包含相关信息,使用getMessage()打印日志,方便定位问题
对于用户,可以使用错误代码,字符串比数值语义更明确些。在spring初期代码中,Rod Johnson设计了一个接口ErrorCoded
1 | public interface ErrorCoded { |
其实也不并是说所有场景都去使用异常,如openapi,最好使用errorCode。
异常与契约
乔新亮指出异常是那些让产品无法履行当初承诺用户的契约的问题。
对于异常设计有5点认知:
1、异常一定要消灭;有异常基本就意味着系统存在风险,一定要消灭异常
2、异常一定要管理:消灭异常是个长期工程,短期要通过管理行为来进行控制
3、对异常的处理水平,会极大影响产品的用户体验:用户规模越大,异常的影响往往越大
4、每个异常都要有具体负责人
5、与终端用户相关的异常,要以最高优先级处理
异常设计包含:异常注册、异常事件触发、异常协作流程以及异常统计。
要关注异常数据、异常发生频次、异常数据的增速和降速。
总结
回到起始问题,对于领域服务,自然OO更好些,抛出特定业务异常,业务语义更加清晰。
性能问题,一是避免发生异常情况,二是通过横向扩展。毕竟业务可运维性更重要。