今天早些时候,中默默的更新了一个名曰的包,这个包和同样处于下的另一个名叫的包名字十分相似,就连介绍也都一致:
从目前的情况来看,基本上错误的处理形式基本已经定型,处理方式则是类似于之前的另一个包,但是具体细节不尽相同。
如何处理error?
在之前介绍文章中提到过包的设计思路,那么在Go团队的实现中,这种思路也得到了继承。先从一个小例子开始:
输出结果:
看起来非常类似于之前的显示内容。而其中则充当了之前的功能。 其中值得一提的是,这个用于包装错误,后续验证错误中也会用到其中的值。
同时,这个包中也包含了几个非常有用的辅助函数,分别是:验证错误类型方法、错误类型转换方法、错误关系链解除方法和提取内层错误方法。我们可以用一个简单的演示来说明这种关系:
输出结果为:
即便是在包裹多层之后,错误类型也能通过方法正确识别:
如果需要打印详细的调用链路,则可以通过标准库相关功能进行输出,比如或者等。
输出链路如下:
但是注意,使用进行包装时,仅能单次包装单个错误,比如下面这种两个错误同时包装时,是会无法识别的:
落地使用
在具体项目实现中,如对外提供的库文件中,我建议可以参考其他语言的实现方式,定义一个特殊的基础错误类型,所有其他错误类型均由此类型派生,则后续外部在使用过程中,只需通过判定错误类型,则可以快速判定错误是否来自于本包,并且可以借助此功能统一单独处理来自于此第三方包的异常。
如果你有其他的建议和疑问,也欢迎在留言区中留言讨论。另外,根据实际实现代码来看,其中还有一些边缘情况未考虑或者未做处理,由于是试验性库,本库在使用过程中需自行承担所带来的风险。
领取专属 10元无门槛券
私享最新 技术干货