一、项目错误处理痛点

我们在业务项目中,经常会遇到以下痛点。

1、缺少统一错误处理方案,代码中随处可见的日志打桩

为了方便接口出错时定位问题,代码中随处可见的日志打桩,并将其看做是一件理所当然的事,然而毫无章法的庞大日志量除了提高维护的工作量,却通常难以达到它该有的目的。

2、请求执行报错后缺少错误堆栈,难以快速定位问题

如下,当底层出现error级别的错误时,在顶层看到的就一个错误信息,请问如何排查?

全错误堆栈设计 - 图1

一张真实的现网案例排查截图

3、第三方组件执行返回的错误,本身不带有堆栈信息

不仅仅是第三方组件,连标准库所有方法返回的error都不带有堆栈,这对业务层统一错误处理造成了很大的挑战。几乎所有业务层代码调用返回的错误,都需要自行使用类似于Wrap方法再包裹一层,以便于业务层自己可以实现错误堆栈返回。这样的维护成本比较大,几乎只能靠CodeReview来人肉保障,一不小心可能会漏掉Wrap处理。

4、错误组件多样,自身项目往往还想当然再封装一层

错误处理的第三方组件也比较多,如何选择?甚至业务项目往往也想自己再封装一层,进一步提高错误处理组件的维护成本。

二、框架全错误堆栈设计

1、统一错误组件

GoFrame框架提供了业内功能最强大的错误处理组件,并且该组件也是框架内部广泛使用的错误组件,降低业务团队的选择成本。

2、统一错误处理方案

GoFrame框架提供了强大的工程设计规范,其中包含了必要的统一的错误处理方案。按照统一框架的工程设计,一些通用性的痛点已通过组件、工具的方式得以解决,使得业务团队能够将精力聚焦于业务本身,开发工作将会事半功倍。

在统一的错误处理方案下,项目中所有的方法调用将会以error返回值作为执行成功与否的依据。如果error不为nil时,及时返回,并将其层层往上传递,在最顶层统一做错误处理。并且,在框架的关键组件已经提供了默认的错误处理逻辑。

全错误堆栈设计 - 图2

3、全组件支持堆栈错误

GoFrame框架所有组件error返回对象均带有错误堆栈!

这是一件很难做到的事情,因为框架提供的组件几乎能够覆盖了大部分业务项目的所有需求,但是框架确实做到了。虽然框架在这块投入的成本比较大,但却是一次性投入、长期收益的事情。这也就意味着,如果业务项目在统一的GoFrame基础框架下,错误处理将会更加简便,错误堆栈丢失的风险得到了极大的降低,项目将会更加稳健、易于快速排错。

4、关键组件支持错误堆栈打印

在框架的关键组件中,提供了对错误堆栈打印的默认处理,以提高易用性,简化使用者负担。这些关键的组件是程序的出口,如HTTP/GRPC ServerCommand命令行。