代码中连续错误处理的潜在风险及替代方案咨询

我在阅读代码时发现了一段已实现的错误处理逻辑，代码如下：

nodes, err := model.AllNodes()
links, err := model.AllLinks()
if err != nil {
    // Do stuff
}

我想咨询这段错误处理逻辑是否会导致不可预测的结果。同时我构思了两种替代实现方案：

方案一：

nodes, err1 := model.AllNodes()
if err1 != nil {
    // Do stuff
}
links, err2 := model.AllLinks()
if err2 != nil {
    // Do stuff
}

方案二（内容未完整给出）：

nodes, err1 := model.AllNodes()
links, err2 := model.AllLinks()
// ...后续逻辑

回答 #

嘿，这个问题抓得非常准——原代码的错误处理确实存在严重隐患，会导致不可预测的结果，咱们一步步拆解来看：

原代码的核心问题 #

在Go里，变量赋值是「后面覆盖前面」的逻辑。原代码的执行流程有致命漏洞：

1. 如果model.AllNodes()返回错误，这个错误会被暂存在err变量中
2. 紧接着调用model.AllLinks()时，不管它是否成功，都会用新的err值覆盖掉之前的错误
3. 最后只检查一次err：如果AllLinks()成功（返回nil），哪怕AllNodes()之前彻底失败，错误处理块也不会执行

这就意味着：你会完全丢失AllNodes()的错误信息，同时可能拿着无效的nodes值继续执行后续逻辑，大概率会引发空指针panic、数据不一致等不可控的bug。

方案一的合理性 #

方案一是Go中处理顺序依赖型操作的标准稳妥写法：

• 每一步操作后立刻检查对应错误，确保上一步成功后再执行下一步
• 不会丢失任何错误信息，每一步的失败都能被及时捕获处理
• 特别适合「必须先成功获取nodes，才能继续处理links」的业务场景

方案二的补充完善（基于你给出的开头） #

如果你的场景是「不管nodes获取是否成功，都要尝试获取links，最后统一处理所有错误」，可以把方案二补全成两种常见形式：

形式1：分别处理独立错误

nodes, err1 := model.AllNodes()
links, err2 := model.AllLinks()

// 先处理nodes的错误
if err1 != nil {
    // 针对AllNodes失败的处理逻辑
}
// 再处理links的错误
if err2 != nil {
    // 针对AllLinks失败的处理逻辑
}

这种方式适合两个操作相互独立，需要分别处理各自错误的场景。

形式2：合并错误统一处理（Go 1.20+支持）

如果你想把所有错误合并成一个统一处理，避免重复代码，可以用errors.Join()：

import "errors"

nodes, err1 := model.AllNodes()
links, err2 := model.AllLinks()

if combinedErr := errors.Join(err1, err2); combinedErr != nil {
    // 处理合并后的错误，其中包含了所有非nil的错误细节
}

这种方式适合需要一次性处理所有错误的场景，同时不会丢失任何错误信息。

总之，原代码的错误处理逻辑绝对不可取，方案一适合顺序依赖场景，补全后的方案二适合独立操作场景，根据你的业务需求选择即可。

内容的提问来源于stack exchange，提问作者Megidd