业务代码中如何处理和使用异常
背景
近期发生多起接口处理异常但是没有报警,不能及时发现和定位。我们展开了对业务代码review和回归,做好异常的处理
异常的使用
在我们的业务中,业务流程大致可以分为参数校验,业务处理,返回数据。当我们对整个方法异常catch并返回某个结果集时。虽然在业务处理上没有问题,但是如果没有对错误日志配置监控报警,那么对于开发维护人员是没有感知的,造成了问题的扩大化。所以正确的抛出异常才是解决如上问题最经济的方法。
问题来了:怎样抛出异常,什么时候抛出异常?
当我们作为服务提供方时:对于我们业务不能处理,不能掌控的流程那么抛出异常很合理。或者对于某个关键参数的校验,如果失败也应该尽早的抛出异常让服务管理平台感知,而不是返回一个带有描述信息的结果集,因为用户不会主动告诉开发人员这个问题。
异常的处理
《猜不透》有句歌词:
“如果忽远忽近的洒脱
是你要的自由
那我宁愿回到一个人生活
如果忽冷忽热的温柔
是你的借口
那我宁愿对你从没认真过”。
这句歌词大概也描述了每位开发人员对于接口调用的感受。那就是——“猜不透”。你调用的接口或许和你那个初恋情人一样“可爱洒脱”。
但是我们不能“到底这感觉谁对谁错 我已不想追究”任由她。
so,知己知彼百战百胜。每一次调用的结果分为:超时,异常,正常。超时由服务框架处理或者自行处理。对于rpc异常,若本次业务核心就是这个调用,如果发生异常,那么很有必要的抛出异常终止服务并及时处理。如:商品详情查询商品信息接口,若原子层获取商品基础信息异常,那么这个业务也没有必要继续进行,并且需要快速报警,进行处理。
但是一些接口不是核心业务:如列表接口,其中渲染列表会调用scf服务获取一些其他信息,这时异常需要我们捕获记录,继续自己的业务处理,而不是抛出异常终止自己的业务。还有一个null 。当我们调用服务接口返回null。如果它是核心接口不要做业务的兼容让步,这个接口应该抛出异常。例如:搜索分类列表页,如果服务返回null。不要轻易的认为是没有搜索命中而返回的。原则上不要让“她”摆布你,不要去猜测,毕竟爱你的人会给你个“痛快”。对于这种“挑逗”,果断抛出异常吧。