Go语言中处理多个错误可通过自定义错误类型或使用errors.Join将多个error聚合为一个返回，既保持单错误返回的简洁性，又可传递详细错误信息。
在Go语言中，函数通常通过返回一个
error
类型的值来指示操作是否成功。但有些场景下，我们可能需要处理或传递不止一个错误信息，比如批量处理操作中，多个子任务都失败了，或者一个复杂的验证过程产生了多个独立的错误。这时候，简单的
(result, error)
模式就显得有些力不从心了。
一个常见的处理思路是，即便函数内部产生了多个错误，最终对外也只返回一个
error
值，但这个
error
值内部却“承载”了所有具体的错误信息。这通常通过自定义错误类型或者利用Go 1.20引入的
errors.Join
函数来实现。本质上，我们是在将多个错误“打包”成一个，以便调用方能够统一接收，并在需要时解包查看详情。
解决方案
当Go函数需要处理并可能返回多个错误值时，以下是几种行之有效且符合Go语言哲学的方法：
1. 自定义错误类型封装多个错误
立即学习“go语言免费学习笔记（深入）”；
这是最灵活也最推荐的方法之一。我们可以定义一个结构体作为自定义错误类型，其中包含一个切片来存储所有遇到的错误，或者包含多个字段来表示不同类型的错误。
package mainimport ( "errors" "fmt" "strings")// ValidationError 代表一个包含多个验证错误的类型type ValidationError struct { Errors []error}// Error 方法实现了 error 接口，用于返回一个聚合的错误信息func (ve *ValidationError) Error() string { if len(ve.Errors) == 0 { return "no validation errors" } msgs := make([]string, len(ve.Errors)) for i, err := range ve.Errors { msgs[i] = err.Error() } return fmt.Sprintf("validation failed with %d errors: %s", len(ve.Errors), strings.Join(msgs, "; "))}// Unwrap 方法允许 errors.Is 和 errors.As 检查内部错误func (ve *ValidationError) Unwrap() []error { return ve.Errors}// ValidateUserData 模拟一个验证用户数据的函数，可能返回多个错误func ValidateUserData(name, email string, age int) error { var errs []error if name == "" { errs = append(errs, errors.New("name cannot be empty")) } if !strings.Contains(email, "@") { errs = append(errs, errors.New("email is not valid")) } if age 0 { return &ValidationError{Errors: errs} } return nil}func main() { // 示例1: 成功情况 if err := ValidateUserData("Alice", "alice@example.com", 25); err != nil { fmt.Println("Validation error:", err) } else { fmt.Println("User data is valid.") } fmt.Println("---") // 示例2: 多个错误情况 err := ValidateUserData("", "bob-example.com", 16) if err != nil { fmt.Println("Validation error:", err) // 检查是否是 ValidationError 类型 var ve *ValidationError if errors.As(err, &ve) { fmt.Println("Detailed validation errors:") for i, subErr := range ve.Errors { fmt.Printf(" %d: %vn", i+1, subErr) } } }}
2. 使用
errors.Join
聚合多个错误 (Go 1.20+)
errors.Join
是Go 1.20引入的一个方便的函数，它接收任意数量的
error
参数，并将它们聚合为一个新的
error
。这个聚合的错误实现了
Unwrap() []error
方法，因此
errors.Is
和
errors.As
依然可以正常工作。
package mainimport ( "errors" "fmt")// ProcessMultipleFiles 模拟处理多个文件，每个文件可能产生错误func ProcessMultipleFiles(filenames []string) error { var allErrors []error for _, filename := range filenames { // 模拟文件处理逻辑 if filename == "bad_file.txt" { allErrors = append(allErrors, fmt.Errorf("failed to read %s: permission denied", filename)) } else if filename == "missing.txt" { allErrors = append(allErrors, fmt.Errorf("file %s not found", filename)) } else { fmt.Printf("Successfully processed %sn", filename) } } if len(allErrors) > 0 { return errors.Join(allErrors...) // 将所有错误聚合为一个 } return nil}func main() { filesToProcess := []string{"file1.txt", "bad_file.txt", "file2.txt", "missing.txt"} err := ProcessMultipleFiles(filesToProcess) if err != nil { fmt.Println("Overall processing failed:", err) // 使用 errors.Is 或 errors.As 检查聚合的错误 if errors.Is(err, errors.New("permission denied")) { // 注意：这里需要检查原始的错误值，而不是格式化后的字符串 fmt.Println(" One or more files had permission issues.") } // 也可以通过 Unwrap 遍历所有内部错误 // (errors.Unwrap 返回单个内部错误，errors.As 可以用于自定义错误类型) // 对于 errors.Join 产生的错误，可以直接用 errors.As 配合 []error 接口 var unwrappedErrs []error if errors.As(err, &unwrappedErrs) { // 注意：errors.As 配合 []error 接口需要 Go 1.20+ fmt.Println(" Individual errors:") for i, subErr := range unwrappedErrs { fmt.Printf(" %d: %vn", i+1, subErr) } } } else { fmt.Println("All files processed successfully.") }}
为什么Go语言标准库通常只返回一个错误值，以及何时需要返回多个错误？
Go语言的设计哲学一直推崇简洁和显式。标准库函数大都遵循
(result, error)
这种经典的返回模式，这使得错误处理变得直观：要么成功得到结果，要么遇到一个错误。这种模式在大多数情况下都足够用，它迫使开发者在遇到错误时立即思考如何处理，而不是让错误悄悄溜走。单个错误值也简化了函数签名，让代码更易读、易懂。
然而，在某些特定场景下，一个单一的
error
值确实无法承载所有需要的信息。我个人认为，主要有以下几种情况需要考虑返回多个错误：
批量操作或并发任务：比如你启动了多个goroutine去下载文件，或者处理一个大文件中的多条记录。如果其中一部分成功，一部分失败，你可能需要收集所有失败的信息，而不是简单地返回“操作失败”。一个聚合的错误能让你知道哪些子任务成功了，哪些失败了，以及失败的具体原因。复杂的数据验证：一个表单提交可能有多个字段需要验证，每个字段都可能产生一个或多个错误。如果只返回第一个遇到的错误，用户体验会很差，因为用户需要反复提交才能修复所有问题。返回一个包含所有验证错误的列表，能让用户一次性看到所有问题并进行修正。部分成功的情况：有些操作可能允许部分成功。例如，一个清理函数试图关闭多个资源，即使其中一些资源关闭失败，其他成功的也应该被记录。此时，一个包含所有失败信息的错误对象就显得很有用。
在这些场景下，仅仅返回
nil
或一个泛泛的
errors.New("operation failed")
显然是不够的。我们需要一种机制来打包和传递更丰富的错误上下文，让调用方能够根据具体情况做出更精细的决策。
如何设计一个包含多个错误信息的自定义错误类型？
设计一个包含多个错误信息的自定义错误类型，核心在于创建一个结构体，它能存储这些错误，并实现
error
接口的
Error()
方法。更进一步，为了与Go标准库的
errors.Is
和
errors.As
函数兼容，我们通常还会实现
Unwrap()
方法（如果内部只有一个错误）或
Unwrap() []error
方法（如果内部包含多个错误，Go 1.20+）。
以之前提到的
ValidationError
为例，我们来深入分析其设计：
type ValidationError struct { Errors []error // 使用切片存储所有具体的错误}// Error 方法：返回一个聚合的字符串表示func (ve *ValidationError) Error() string { if len(ve.Errors) == 0 { return "no validation errors" } // 拼接所有内部错误的字符串表示，提供一个概览 msgs := make([]string, len(ve.Errors)) for i, err := range ve.Errors { msgs[i] = err.Error() } return fmt.Sprintf("validation failed with %d errors: %s", len(ve.Errors), strings.Join(msgs, "; "))}// Unwrap 方法：让 errors.Is 和 errors.As 能够检查内部错误// 对于包含多个错误的类型，Go 1.20+ 推荐实现 Unwrap() []errorfunc (ve *ValidationError) Unwrap() []error { return ve.Errors}
设计考量：
内部存储：最直接的方式是使用
[]error
切片来存储所有独立的错误。如果错误类型是固定的几种，也可以考虑直接在结构体中定义多个
error
字段（例如
NameError error; EmailError error
），但这会限制其通用性。
Error()
方法：这是
error
接口的唯一要求。它的实现应该返回一个对用户友好的、能够概括所有内部错误的字符串。通常我们会将所有内部错误的
Error()
字符串拼接起来，加上一些上下文信息。
Unwrap()
方法：这个方法是与
errors
包深度集成的关键。如果你的自定义错误类型只封装了一个底层错误，实现
Unwrap() error
即可。如果像
ValidationError
这样封装了多个错误，Go 1.20及更高版本推荐实现
Unwrap() []error
。这允许
errors.Is
和
errors.As
在遍历内部错误时，能够识别并匹配到你期望的特定错误类型或哨兵错误。例如，你可以通过
errors.Is(myMultiError, ErrSpecificValidationRule)
来检查是否包含某个特定的验证错误。创建和返回：在函数内部，当收集到多个错误时，创建一个
ValidationError
实例，并将所有错误填充进去，然后返回这个自定义错误。调用方处理：调用方接收到错误后，首先可以打印其
Error()
字符串获取概览。如果需要详细处理，可以通过
errors.As(&myCustomError, &target)
来判断是否是
ValidationError
类型，如果是，就可以安全地访问其内部的
errors
切片，逐一处理每个子错误。
这种设计模式，既保持了Go语言单错误返回的简洁性（对外仍是一个
error
），又提供了足够的灵活性和深度，让调用方可以根据业务需求，选择性地深入挖掘错误细节。
使用
errors.Join
errors.Join
聚合多个错误：优势与适用场景
errors.Join
是Go 1.20版本引入的一个非常实用的函数，它提供了一种标准化的方式来将多个独立的
error
值组合成一个单一的
error
。它的函数签名很简单：
func Join(errs ...error) error
。
优势：
简洁性：相比于手动创建自定义错误结构体并实现
Error()
和
Unwrap()
方法，
errors.Join
提供了一个即插即用的解决方案，代码量更少，更易于理解。标准库支持：作为标准库的一部分，它具有良好的兼容性和可维护性。使用
errors.Join
产生的错误，可以直接与
errors.Is
和
errors.As
配合使用，无需额外实现接口。兼容性：
errors.Join
返回的错误值会自动实现
Unwrap() []error
接口，这意味着你可以通过
errors.As(err, &[]error{})
来提取其内部的原始错误切片，或者通过
errors.Is(err, targetErr)
来检查聚合错误中是否包含某个特定的错误。可读性：它明确表达了“这些错误是一起发生的”的意图，提高了代码的可读性。
适用场景：
errors.Join
特别适用于那些需要收集多个独立操作结果，并且这些操作可能并行或串行发生，但最终需要统一报告所有失败情况的场景。
资源清理：在
defer
语句中，你可能需要关闭多个资源（文件、网络连接、数据库句柄等）。如果每个关闭操作都可能失败，你可以将所有失败的错误通过
errors.Join
聚合起来，在函数结束时统一返回。
func cleanupResources() (err error) { var errs []error f1, _ := os.Open("file1.txt") // 假设f1, f2, f3是需要关闭的资源 f2, _ := os.Open("file2.txt") f3, _ := os.Open("file3.txt") if e := f1.Close(); e != nil { errs = append(errs, fmt.Errorf("closing f1: %w", e)) } if e := f2.Close(); e != nil { errs = append(errs, fmt.Errorf("closing f2: %w", e)) } if e := f3.Close(); e != nil { errs = append(errs, fmt.Errorf("closing f3: %w", e)) } if len(errs) > 0 { return errors.Join(errs...) } return nil}
并发任务错误收集：当启动多个goroutine执行任务时，每个goroutine都可能返回错误。你可以通过一个通道或一个受互斥锁保护的切片来收集这些错误，然后在所有goroutine完成后，使用
errors.Join
将它们合并。
多阶段操作：一个复杂的业务流程可能包含多个独立的子步骤，每个步骤都可能失败。如果允许部分成功，并且需要报告所有失败的步骤，
errors.Join
是一个不错的选择。例如，一个数据导入工具可能需要验证数据、写入数据库、更新缓存，每个环节都可能出错。
需要注意的是，
errors.Join
聚合的错误，其
Error()
方法会以换行符分隔每个原始错误的
Error()
字符串。这意味着它的输出可能比自定义错误类型更简单直接，但可能不如自定义类型那样能提供高度定制化的错误描述。选择哪种方式，取决于你对错误信息呈现和处理的精细程度要求。如果只需要一个简单的错误列表，
errors.Join
是一个快速而优雅的方案。如果需要更复杂的错误结构或业务逻辑，自定义错误类型则更具优势。
以上就是Golang函数返回多个错误值处理示例的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1407972.html
微信扫一扫 
支付宝扫一扫 
![linux系统下codeblocks控制台打印中文乱码[通俗易懂]](https://www.chuangxiangniao.com/wp-content/uploads/2025/10/175245629895736.jpg)
![linux系统下codeblocks控制台打印中文乱码[通俗易懂]](https://www.chuangxiangniao.com/wp-content/uploads/2025/10/175245629849970.jpg)
![linux系统下codeblocks控制台打印中文乱码[通俗易懂]](https://www.chuangxiangniao.com/wp-content/uploads/2025/10/175245629946891.jpg)
![linux系统下codeblocks控制台打印中文乱码[通俗易懂]](https://www.chuangxiangniao.com/wp-content/uploads/2025/10/175245629944402.jpg)
