业务代码中如何处理和使用异常

业务代码中如何处理和使用异常

背景

近期发生多起接口处理异常但是没有报警，不能及时发现和定位。我们展开了对业务代码review和回归，做好异常的处理

异常的使用

在我们的业务中，业务流程大致可以分为参数校验，业务处理，返回数据。当我们对整个方法异常catch并返回某个结果集时。虽然在业务处理上没有问题，但是如果没有对错误日志配置监控报警，那么对于开发维护人员是没有感知的，造成了问题的扩大化。所以正确的抛出异常才是解决如上问题最经济的方法。

问题来了：怎样抛出异常，什么时候抛出异常？

当我们作为服务提供方时：对于我们业务不能处理，不能掌控的流程那么抛出异常很合理。或者对于某个关键参数的校验，如果失败也应该尽早的抛出异常让服务管理平台感知，而不是返回一个带有描述信息的结果集，因为用户不会主动告诉开发人员这个问题。

异常的处理

《猜不透》有句歌词：

“如果忽远忽近的洒脱

是你要的自由

那我宁愿回到一个人生活

如果忽冷忽热的温柔

是你的借口

那我宁愿对你从没认真过”。

这句歌词大概也描述了每位开发人员对于接口调用的感受。那就是——“猜不透”。你调用的接口或许和你那个初恋情人一样“可爱洒脱”。

但是我们不能“到底这感觉谁对谁错 我已不想追究”任由她。

so，知己知彼百战百胜。每一次调用的结果分为：超时，异常，正常。超时由服务框架处理或者自行处理。对于rpc异常，若本次业务核心就是这个调用，如果发生异常，那么很有必要的抛出异常终止服务并及时处理。如：商品详情查询商品信息接口，若原子层获取商品基础信息异常，那么这个业务也没有必要继续进行，并且需要快速报警，进行处理。

但是一些接口不是核心业务：如列表接口，其中渲染列表会调用scf服务获取一些其他信息，这时异常需要我们捕获记录，继续自己的业务处理，而不是抛出异常终止自己的业务。还有一个null 。当我们调用服务接口返回null。如果它是核心接口不要做业务的兼容让步，这个接口应该抛出异常。例如：搜索分类列表页，如果服务返回null。不要轻易的认为是没有搜索命中而返回的。原则上不要让“她”摆布你，不要去猜测，毕竟爱你的人会给你个“痛快”。对于这种“挑逗”，果断抛出异常吧。

转载于:https://my.oschina.net/u/3418748/blog/3093832