Go语言中处理多个错误可通过自定义错误类型或使用errors.Join将多个error聚合为一个返回，既保持单错误返回的简洁性，又可传递详细错误信息。
在Go语言中，函数通常通过返回一个
error类型的值来指示操作是否成功。但有些场景下，我们可能需要处理或传递不止一个错误信息，比如批量处理操作中，多个子任务都失败了，或者一个复杂的验证过程产生了多个独立的错误。这时候，简单的
(result, error)模式就显得有些力不从心了。
一个常见的处理思路是，即便函数内部产生了多个错误，最终对外也只返回一个
error值，但这个
error值内部却“承载”了所有具体的错误信息。这通常通过自定义错误类型或者利用Go 1.20引入的
errors.Join函数来实现。本质上，我们是在将多个错误“打包”成一个，以便调用方能够统一接收，并在需要时解包查看详情。
解决方案
当Go函数需要处理并可能返回多个错误值时，以下是几种行之有效且符合Go语言哲学的方法：
1. 自定义错误类型封装多个错误
立即学习“go语言免费学习笔记（深入）”；
这是最灵活也最推荐的方法之一。我们可以定义一个结构体作为自定义错误类型，其中包含一个切片来存储所有遇到的错误，或者包含多个字段来表示不同类型的错误。
package main
import (
"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 < 18 {
errs = append(errs, errors.New("user must be at least 18 years old"))
}
if len(errs) > 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: %v\n", i+1, subErr)
}
}
}
}2. 使用 errors.Join
聚合多个错误 (Go 1.20+)
errors.Join是Go 1.20引入的一个方便的函数，它接收任意数量的
error参数，并将它们聚合为一个新的
error。这个聚合的错误实现了
Unwrap() []error方法，因此
errors.Is和
errors.As依然可以正常工作。
package main
import (
"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 %s\n", 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: %v\n", 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() []error
func (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是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是一个快速而优雅的方案。如果需要更复杂的错误结构或业务逻辑，自定义错误类型则更具优势。
