一、项目错误处理痛点

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

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

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

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

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

全错误堆栈设计 - 图1

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

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

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

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

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

二、框架全错误堆栈设计

1、统一错误组件

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

2、统一错误处理方案

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

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

全错误堆栈设计 - 图2

3、全组件支持堆栈错误

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

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

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

🔥重要的事情说三遍!🔥

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

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

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