在 golang 中,错误处理应优先使用结构体实现 Error 接口以携带额外信息,1. 自定义错误类型通过实现 error() 方法支持类型判断与信息扩展;2. 简单错误可用 errors.new 或 fmt.errorf,但不便于类型提取;3. 使用 fmt.errorf 的 %w 动词包装错误可保留原始信息;4. 解包错误可通过 errors.unwrap、errors.is 和 errors.as 遍历错误链进行匹配或类型提取;5. 实践中应优先使用 errors.as 判断类型,避免随意包装无上下文的错误,关键路径添加上下文再包装,并避免字符串比较以提升可靠性与可维护性。
在 golang 中,错误处理是程序设计的重要组成部分。
errors
库提供了创建、包装和解包错误的能力,让我们可以写出更清晰、可维护的错误逻辑。下面我们就来看看如何使用
errors
包来创建自定义错误,并演示错误包装与解包的最佳实践。
自定义错误类型:实现 error 接口
最基础的方式是通过定义一个结构体并实现
error
接口的
Error() String
方法:
type MyError struct { Msg string } func (e MyError) Error() string { return "MyError: " + e.Msg }
这样你就可以像使用标准错误一样使用它:
立即学习“go语言免费学习笔记(深入)”;
err := MyError{"something went wrong"} fmt.Println(err)
这种方式适合需要携带额外信息的场景,比如错误码、状态、发生位置等。你可以扩展这个结构体,加入更多字段以供后续处理。
使用 errors.New 和 fmt.Errorf 创建简单错误
对于不需要附加额外信息的错误,直接使用
errors.New
就够用了:
err := errors.New("this is a simple error")
如果需要格式化错误信息,可以用
fmt.Errorf
:
err := fmt.Errorf("invalid value: %d", val)
但要注意的是,这两种方式创建的错误都是“裸”的字符串错误,不便于做类型判断或提取上下文信息。所以,在需要做错误类型区分时,还是建议用上面的结构体方式。
错误包装(Wrap):保留原始错误信息
Go 1.13 引入了
fmt.Errorf
的
%w
动词来进行错误包装:
err := fmt.Errorf("failed to read config: %w", originalErr)
这会把
originalErr
包装进新的错误中,方便后续调用者使用
errors.Unwrap()
或
errors.As()
提取原始错误。
注意:只有使用 %w 格式符包装的错误才能被正确解包。其他方式(如拼接字符串)无法保留原始错误结构。
错误解包(Unwrap):提取原始错误进行判断
如果你得到了一个被包装过的错误,想判断它是否是由某个特定错误引起的,可以用以下方法:
-
errors.Unwrap(err)
:获取包装错误的下一层错误。
-
errors.Is(err, target)
:判断某层错误是否等于目标错误。
-
errors.As(err, &target)
:判断某层错误是否是指定类型的错误。
例如:
if errors.Is(err, os.ErrNotExist) { // 处理文件不存在的情况 }
或者检查自定义错误类型:
var myErr *MyError if errors.As(err, &myErr) { fmt.Println("Got a MyError with message:", myErr.Msg) }
这些方法会自动遍历整个错误链,直到找到匹配项为止,非常实用。
实践建议:怎么用才合理?
-
优先使用 errors.As 而不是 type switch
因为errors.As
可以处理嵌套包装的错误,而 type switch 只能判断当前层级的错误类型。
-
不要随意包装所有错误
如果你只是传递错误而不加任何上下文信息,就不需要用%w
。否则会让错误链变得复杂且难以理解。
-
在关键路径上添加上下文信息再包装
比如在函数调用栈的高层加上操作失败的原因,这样调试时更容易定位问题。 -
避免只比较错误字符串
字符串比较不稳定,容易因为拼写错误或语句变化而出错。应该尽量使用类型或变量对比。
基本上就这些。Golang 的错误机制虽然看起来简单,但在实际项目中要处理得当,还是要靠合理的包装和解包策略。用好
errors
包提供的工具,可以让你的错误处理更清晰、更可靠。
评论(已关闭)
评论已关闭