一、项目错误处理痛点
我们在业务项目中,经常会遇到以下痛点。
1、缺少统一错误处理方案,代码中随处可见的日志打桩
为了方便接口出错时定位问题,代码中随处可见的日志打桩,并将其看做是一件理所当然的事,然而毫无章法的庞大日志量除了提高维护的工作量,却通常难以达到它该有的目的。
2、请求执行报错后缺少错误堆栈,难以快速定位问题
如下,当底层出现 error
级别的错误时,在顶层看到的就一个错误信息,请问如何排查?
一张真实的现网案例排查截图
3、第三方组件执行返回的错误,本身不带有堆栈信息
不仅仅是第三方组件,连标准库所有方法返回的 error
都不带有堆栈,这对业务层统一错误处理造成了很大的挑战。几乎所有业务层代码调用返回的错误,都需要自行使用类似于 Wrap
方法再包裹一层,以便于业务层自己可以实现错误堆栈返回。这样的维护成本比较大,几乎只能靠 CodeReview
来人肉保障,一不小心可能会漏掉 Wrap
处理。
4、错误组件多样,自身项目往往还想当然再封装一层
错误处理的第三方组件也比较多,如何选择?甚至业务项目往往也想自己再封装一层,进一步提高错误处理组件的维护成本。