一、项目错误处理痛点

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

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

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

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

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

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

二、框架全错误堆栈设计

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

2、统一错误处理方案

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

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

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

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