一、项目错误处理痛点

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

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

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

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

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

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

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

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

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

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

二、框架全错误堆栈设计

1、统一错误组件

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

2、统一错误处理方案

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

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

3、全组件支持堆栈错误

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

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

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

🔥重要的事情说三遍！🔥

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

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

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