自定义错误类型通过结构体实现error接口，可携带时间、位置等详细信息，如MyError记录时间和错误描述；错误包装使用%w动词将底层错误嵌入，保留原始上下文，便于通过errors.As解包获取根源错误；处理多返回值错误需及时检查并传递上下文；APIError示例包含错误码、消息和详情，提升调试效率；错误包装适用于保留上下文，错误链适合追踪传播路径，两者可结合使用；自定义错误用于需细分错误类型或附加信息的场景，标准错误适用于简单通用情况，如io.EOF表示文件结束。
Golang的
errors
库允许你创建和处理错误，自定义错误类型能提供更精确的错误信息，错误包装则能保留错误的原始上下文，方便调试。
自定义错误类型和包装现有错误，提供更丰富的错误信息和上下文。
自定义错误类型：结构体与接口的巧妙结合
Golang中并没有像其他语言那样的
try-catch
机制，而是通过显式地返回
error
类型来处理错误。 要想自定义错误，通常会定义一个结构体，并让这个结构体实现
error
接口。 这样做的好处是可以携带更多的错误信息，例如错误发生的具体位置、参数值等等。
立即学习“go语言免费学习笔记（深入）”；
package mainimport ( "fmt" "time")type MyError struct { When time.Time What string}func (e MyError) Error() string { return fmt.Sprintf("%v: %v", e.When, e.What)}func run() error { return MyError{ When: time.Now(), What: "Something went wrong", }}func main() { if err := run(); err != nil { fmt.Println(err) }}
上面的代码定义了一个
MyError
结构体，包含了错误发生的时间和错误信息。
Error()
方法实现了
error
接口，返回一个格式化的错误字符串。
错误包装：保留上下文，追溯根源
错误包装是指将一个错误包装到另一个错误中，这样可以保留原始错误的上下文信息。Golang 1.13引入了
errors.Wrap
和
fmt.Errorf
的
%w
动词来实现错误包装。
package mainimport ( "errors" "fmt" "os")func readFile(filename string) ([]byte, error) { f, err := os.Open(filename) if err != nil { return nil, fmt.Errorf("failed to open file: %w", err) } defer f.Close() b := make([]byte, 100) n, err := f.Read(b) if err != nil { return nil, fmt.Errorf("failed to read file: %w", err) } return b[:n], nil}func main() { _, err := readFile("nonexistent_file.txt") if err != nil { fmt.Println(err) // 解包错误，直到找到原始错误 var pathError *os.PathError if errors.As(err, &pathError) { fmt.Println("Failed at path:", pathError.Path) } }}
在这个例子中，
readFile
函数在打开文件和读取文件时都使用了
fmt.Errorf
的
%w
动词来包装错误。这样，即使在
main
函数中捕获到错误，也可以通过
errors.As
来解包错误，获取原始的
os.PathError
，从而知道是哪个文件路径出了问题。
如何优雅地处理多个返回值中的错误？
Golang函数经常返回多个值，其中一个通常是
error
。 处理这种情况需要一些技巧，尤其是在链式调用中。
package mainimport ( "fmt" "os")func processFile(filename string) error { f, err := os.Open(filename) if err != nil { return fmt.Errorf("failed to open %s: %w", filename, err) } defer f.Close() // ... 更多操作 return nil}func main() { err := processFile("my_file.txt") if err != nil { fmt.Println(err) }}
这里的关键在于，每次调用可能返回错误的函数时，都要立即检查错误，并进行处理或返回。 错误信息应包含足够的上下文，方便定位问题。
自定义错误类型应该包含哪些信息？
自定义错误类型的设计取决于具体的应用场景，但通常应该包含以下信息：
错误发生的时间错误发生的具体位置（文件名、函数名、行号）错误码相关的参数值错误描述信息
package mainimport ( "fmt" "time")type APIError struct { Time time.Time Code int Message string Details map[string]interface{}}func (e APIError) Error() string { return fmt.Sprintf("[%d] %s: %v", e.Code, e.Message, e.Details)}func callAPI() error { return APIError{ Time: time.Now(), Code: 500, Message: "Internal Server Error", Details: map[string]interface{}{ "endpoint": "/users", "method": "GET", }, }}func main() { err := callAPI() if err != nil { fmt.Println(err) }}
这个例子中的
APIError
包含了错误码、错误信息和详细信息，可以帮助开发者更好地理解错误发生的原因。
错误包装与错误链：如何选择合适的策略？
错误包装和错误链是两种不同的错误处理策略。错误包装是将一个错误包装到另一个错误中，保留原始错误的上下文信息。错误链则是将多个错误连接起来，形成一个链式结构，记录错误的传递路径。
选择哪种策略取决于具体的应用场景。如果需要保留原始错误的上下文信息，可以选择错误包装。如果需要记录错误的传递路径，可以选择错误链。 在实际应用中，也可以将这两种策略结合起来使用。
什么时候应该使用自定义错误类型，什么时候应该使用标准错误？
使用自定义错误类型的情况：
需要携带更多的错误信息需要区分不同类型的错误需要对错误进行特定的处理
使用标准错误的情况：
错误信息简单明了不需要对错误进行特定的处理
一般来说，对于应用程序内部的错误，可以使用自定义错误类型。对于与外部系统交互时发生的错误，可以使用标准错误。 例如，
io.EOF
就是一个常用的标准错误，表示已经读取到文件末尾。
以上就是Golang errors库自定义错误与包装技巧的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1403761.html
微信扫一扫 
支付宝扫一扫 
