Go语言推荐在函数返回多值时立即检查error，若err不为nil则优先处理错误，避免使用无效结果。核心做法是使用if err != nil进行显式判断，确保错误被处理，提升代码健壮性。典型模式为：调用函数后立即检查error，根据err是否为nil决定后续流程。可通过fmt.Errorf配合%w包装错误以添加上下文，使用errors.Is判断是否为特定哨兵错误（如os.ErrNotExist），用errors.As提取自定义错误类型中的信息。常见最佳实践包括：尽早检查并返回错误、保持返回值与错误的一致性、避免忽略错误或重复记录日志、创建有意义的错误信息、定义自定义错误类型和哨兵错误，同时防止敏感信息泄露。该显式错误处理机制相比异常更清晰、可控，强调错误是程序正常流程的一部分，需主动应对而非依赖隐式捕获。
在Golang中，当函数返回多个值，尤其是遵循
(结果, 错误)
error
error
nil
在Go语言中，处理多返回值函数（尤其是
(value, error)
if err != nil { ... }我们来看一个典型的例子：
package main
import (
"errors"
"fmt"
"os"
)
// ReadFileContent 模拟读取文件内容，可能返回内容和错误
func ReadFileContent(filename string) ([]byte, error) {
// 模拟文件不存在的错误
if filename == "non_existent.txt" {
return nil, os.ErrNotExist
}
// 模拟其他读取错误
if filename == "corrupted.txt" {
return nil, errors.New("file is corrupted")
}
// 假设成功读取
content := []byte(fmt.Sprintf("This is content from %s", filename))
return content, nil
}
func main() {
// 场景一：成功读取
data, err := ReadFileContent("my_document.txt")
if err != nil {
// 错误处理：这里可以记录日志、向用户显示错误信息等
fmt.Printf("Error reading file 'my_document.txt': %v\n", err)
// 通常会在这里选择返回或者采取补救措施
// return // 如果在函数内部，可能会直接返回
} else {
fmt.Printf("Successfully read 'my_document.txt': %s\n", string(data))
}
fmt.Println("---")
// 场景二：文件不存在
data, err = ReadFileContent("non_existent.txt")
if err != nil {
// 错误处理：检查特定类型的错误
if errors.Is(err, os.ErrNotExist) {
fmt.Printf("Error: File 'non_existent.txt' does not exist.\n")
} else {
fmt.Printf("Error reading file 'non_existent.txt': %v\n", err)
}
} else {
fmt.Printf("Successfully read 'non_existent.txt': %s\n", string(data))
}
fmt.Println("---")
// 场景三：文件损坏
data, err = ReadFileContent("corrupted.txt")
if err != nil {
fmt.Printf("Error reading file 'corrupted.txt': %v\n", err)
} else {
fmt.Printf("Successfully read 'corrupted.txt': %s\n", string(data))
}
}这段代码展示了最基本的处理逻辑：调用函数后，立即检查
err
err
nil
立即学习“go语言免费学习笔记（深入）”；
我个人觉得，这种显式处理虽然有时会显得代码有些冗长，但它强制开发者思考每一步可能出现的错误，这比那些隐式的异常捕获机制要来得实在和可控。你不会因为忘记写
try-catch
err
这真的是一个老生常谈的话题了，但每次讨论Go的错误处理，都绕不开它。在我看来，Go语言设计者选择显式错误处理，而不是像Java、Python那样的异常机制，主要基于几个核心理念：清晰性、可预测性和控制流的明确性。
首先，异常机制，特别是那些可以被“抛出”和“捕获”的运行时异常，它们在代码中引入了一种非局部的控制流。一个函数可能在任何地方抛出异常，而调用者必须知道并准备好捕获它。这导致了一个问题：你很难一眼看出一个函数可能抛出哪些异常，或者某个异常是在哪里被抛出的。这就好比你在看一本书，突然某一页有个脚注告诉你“请翻到第200页继续阅读”，然后第200页又让你翻到第50页，整个阅读体验就变得支离破碎。
Go的
(value, error)
err
_
我个人在从其他语言转到Go的时候，一开始也觉得这种方式有点“笨拙”，代码里充斥着
if err != nil
catch
所以，Go不是没有“异常”，而是把“异常”看作是“正常”的函数返回值，只不过这个返回值代表了失败的状态。这使得程序的行为更加可预测，也更容易调试。
在实际项目中，我们很少能在错误发生的第一时间就完全“解决”它。更多时候，我们需要将错误向上层调用者传递，并在这个过程中添加更多的上下文信息，或者根据错误的类型采取不同的处理策略。这正是Go语言错误处理的进阶之处。
1. 向上层传播并添加上下文
最常见的做法是，当前函数遇到错误后，并不能完全处理，需要将错误返回给它的调用者。但仅仅返回原始错误往往不够，因为上层调用者可能不知道这个错误是在哪个环节、因为什么原因发生的。这时候，我们就需要给错误“加料”——添加上下文信息。
Go 1.13 引入的
fmt.Errorf
%w
package main
import (
"errors"
"fmt"
"os"
)
// CustomError 模拟一个自定义错误类型
type CustomError struct {
Op string
Err error
}
func (e *CustomError) Error() string {
return fmt.Sprintf("operation %s failed: %v", e.Op, e.Err)
}
// Unwrap 允许 CustomError 被 errors.Is 和 errors.As 检查
func (e *CustomError) Unwrap() error {
return e.Err
}
// LoadConfig 模拟加载配置文件，可能失败
func LoadConfig(path string) ([]byte, error) {
// 模拟文件读取失败
if path == "/etc/app/bad_config.json" {
return nil, os.ErrPermission // 假设是权限问题
}
// 模拟配置解析失败
if path == "/etc/app/invalid_config.json" {
return nil, errors.New("invalid JSON format")
}
return []byte("config data"), nil
}
// InitApplication 初始化应用，调用 LoadConfig
func InitApplication(configPath string) error {
_, err := LoadConfig(configPath)
if err != nil {
// 使用 %w 包装原始错误，添加当前操作的上下文
return fmt.Errorf("failed to initialize application: %w", err)
}
fmt.Printf("Application initialized with config from %s\n", configPath)
return nil
}
func main() {
// 场景一：配置加载失败，权限问题
err := InitApplication("/etc/app/bad_config.json")
if err != nil {
fmt.Printf("Main function caught error: %v\n", err)
// 检查原始错误类型
if errors.Is(err, os.ErrPermission) {
fmt.Println("Hint: Check file permissions for the config file.")
}
}
fmt.Println("---")
// 场景二：配置解析失败
err = InitApplication("/etc/app/invalid_config.json")
if err != nil {
fmt.Printf("Main function caught error: %v\n", err)
// 检查是否是特定的“无效JSON格式”错误
if errors.Is(err, errors.New("invalid JSON format")) { // 注意：errors.New 每次创建新错误，直接比较可能不准确
fmt.Println("Hint: Config file has invalid JSON format.")
}
}
fmt.Println("---")
// 场景三：自定义错误类型的使用
err = &CustomError{Op: "database_query", Err: errors.New("connection refused")}
wrappedErr := fmt.Errorf("failed to process request: %w", err)
fmt.Printf("Wrapped error: %v\n", wrappedErr)
if errors.As(wrappedErr, &CustomError{}) {
fmt.Println("Detected a CustomError within the wrapped error chain.")
}
}通过
fmt.Errorf("some context: %w", originalErr)2. 处理不同类型的错误：errors.Is
errors.As
仅仅传播错误还不够，有时候我们需要根据错误的具体类型来决定如何处理。Go提供了
errors.Is
errors.As
errors.Is(err, target)
os.ErrNotExist
target
true
// 假设 err 是 InitApplication 返回的错误
if errors.Is(err, os.ErrPermission) {
fmt.Println("Error is a permission denied issue.")
}errors.As(err, &target)
target
*MyCustomError
// 假设 err 是一个包装了 CustomError 的错误
var customErr *CustomError
if errors.As(err, &customErr) {
fmt.Printf("Found custom error: Operation '%s' failed.\n", customErr.Op)
// 进一步处理 customErr
}我个人觉得，
%w
errors.Is
errors.As
虽然Go的错误处理模式简单直接，但在实际开发中，还是有一些常见的陷阱需要避免，同时也有一些最佳实践可以帮助我们写出更健壮、更易维护的代码。
常见陷阱：
忽略错误： 这是最常见的陷阱，尤其是在快速开发或调试时。很多人习惯性地写
_, err := someFunc()
err
someFunc()
err
_
// ❌ 错误做法：直接忽略错误
// _, _ = someFuncThatReturnsError() // 或者干脆不接收返回值
// fmt.Println("操作完成！") // 实际上可能已经失败了过度日志或日志不足： 有些人习惯在每个
if err != nil
返回 nil
nil
(zeroValue, err)
(validValue, nil)
err != nil
value
nil
0
返回泛型错误，丢失上下文： 仅仅返回
errors.New("something failed")fmt.Errorf("context: %w", originalErr)不使用 errors.Is
errors.As
err == someError
strings.Contains(err.Error(), "some string")
errors.Is
errors.As
最佳实践：
尽早检查，尽早返回： 这是Go错误处理的核心思想。当函数遇到错误时，立即检查
err
data, err := readFromFile(filename)
if err != nil {
return nil, fmt.Errorf("failed to read file: %w", err)
}
// 只有在没有错误时才继续处理 data
parsedData, err := parseData(data)
if err != nil {
return nil, fmt.Errorf("failed to parse data: %w", err)
}
return parsedData, nil创建有意义的错误信息： 错误信息应该清晰、简洁，并包含足够的信息来帮助调试。避免使用模糊的“操作失败”之类的描述。
定义自定义错误类型： 对于应用程序特有的、需要特殊处理的错误，可以定义自定义错误类型。这让
errors.As
type UserNotFoundError struct {
UserID string
}
func (e *UserNotFoundError) Error() string {
return fmt.Sprintf("user with ID %s not found", e.UserID)
}
// ...
var userNotFoundErr *UserNotFoundError
if errors.As(err, &userNotFoundErr) {
fmt.Printf("User %s was not found in the system.\n", userNotFoundErr.UserID)
}使用哨兵错误： 对于一些通用的、预期的错误条件，可以定义为全局的
var
errors.Is
var ErrInvalidInput = errors.New("invalid input provided")
// ...
if errors.Is(err, ErrInvalidInput) {
// Handle invalid input
}避免在错误中包含敏感信息： 错误信息可能会被记录到日志或暴露给用户，所以不要在错误中包含密码、API密钥等敏感数据。
我个人觉得，写好Go的错误处理，很大程度上是培养一种严谨的编程习惯。它要求你对代码的每一个可能失败的点都有所预见和安排，而不是寄希望于一个全局的捕获机制。这可能需要一些时间来适应，但最终会让你写出更稳定、更可靠的软件。
以上就是Golang中当函数返回多个值时错误处理代码的推荐写法的详细内容，更多请关注php中文网其它相关文章！
每个人都需要一台速度更快、更稳定的 PC。随着时间的推移，垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是，许多工具可以让 Windows 保持平稳运行。
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号
1003
收藏
