1 回答
TA贡献1842条经验 获得超21个赞
免责声明:我不知道以下建议是否可以被视为“标准”或“广泛接受”。
我应该为此使用错误包装吗?
简短的回答:是的(我会这样做)。
Go 1.12 及更早版本
当我需要错误来传达某些特定含义时,我会做什么,而不放弃接口error
,我创建一个实现错误接口的包装器 - Error() string
-。该包装包含我需要的所有额外信息。
如果调用者知道这些额外信息的存在,它可以通过强制转换来解开错误并找到这些信息。额外的好处是,不知情的调用者可以将错误作为通用的error
.
type MyError struct {
DeferredError error
}
// Implements 'error' interface
func (e MyError) Error() string {
// format to string
}
func someFunc() error {
// might return an instance of MyError
}
...
// Caller code
err := someFunc()
if err != nil {
if myErr, ok := err.(*MyError); ok {
// here you can access the wrapped info
fmt.Println(myErr.DeferredError)
} else {
// otherwise handle the error generically
}
}
转到 1.13 及以上
使用 Go.13,您可以用来errors.As解开错误。来自官方文档:
[方法] As 查找 err 链中与 target 匹配的第一个错误,如果是,则将 target 设置为该错误值并返回 true。该链由 err 本身和通过重复调用 Unwrap 获得的错误序列组成。
var myErr *MyError
if errors.As(err, &myErr) {
// here you can access the wrapped info
fmt.Println(myErr.DeferredError)
} else {
// otherwise handle the error generically
}
正如文档所说,该myErr变量是作为调用的副作用而填充的As。
- 1 回答
- 0 关注
- 68 浏览
添加回答
举报