一、项目错误处理痛点

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

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

为了方便接口出错时定位问题，代码中随处可见的日志打桩，并将其看做是一件理所当然的事，影响着后续项目维护的思路。

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

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

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

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

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

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

二、框架全错误堆栈设计

1、统一错误组件

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

2、统一错误处理方案

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

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

3、全组件支持堆栈错误

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

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

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

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