编程语言研究书库
Prompting Go(AI 辅助 Go 系统开发)

错误处理与调试 — Go 为什么不要异常,以及崩了怎么办

错误处理与调试 — Go 为什么不要异常,以及崩了怎么办

这一章讲什么: Go 故意不用 try/catch 异常机制,改用「错误就是普通返回值」—— 这个决定怎么落实成每天写的代码;真崩溃了(panic)怎么办;日志和调试工具箱里有什么; 四个最常见的运行时坑长什么样、怎么抓。 它在全书链条里的位置: 第 03 章给了你结构,这一章给结构装上「出故障时的行为」。 后面每章都有它的影子:数据库错误的传递(第 06 章)、API 错误响应(第 07 章)、 流水线的错误策略(第 08 章)、生产的 panic 兜底(第 10 章)。 读法警示: 这一章是全书最不能「AI 代劳」的一章——AI 最擅长生成看起来对、 实际吞掉了错误的代码(本章 §8 第一个例子就是它)。

1. 顶层全景:三条失败路径

  可预期的失败(文件不存在、网络超时、参数不合法)
      └──► 走 error 返回值:每层包一层上下文,逐层向上传
  资源清理(关文件、解锁、刷缓冲)
      └──► 走 defer:函数无论怎么退出都执行
  真正的崩溃(数组越界、nil 解引用、程序不变量被破坏)
      └──► 走 panic → 沿栈上卷 → defer 照常跑 → recover 拦下(只在边界拦)

主线例子(贯穿本章): 一个「启动时读配置文件」的链条,每层各添一句上下文, 最后演示怎么用 errors.Is 找回最初原因、用 errors.As 抽出结构化字段; 中途插播 nil 指针 panic 和 defer/recover 的兜底。命令输出是演示性的, 代码骨架照原书各节的示例拼成一条链。

2. 核心原理:错误是值,不是控制流

2.1 解决什么问题:异常的隐藏控制流

Java、Python、C++ 用异常:一处 throw,调用栈一层层往上弹,某处 catch 接住。 问题:读一个函数时,你没法从代码里看出它会失败在哪里——失败路径藏在调用树的 某个深处,不扫完整棵树不知道1。

Go 的选择是三条「没有」:没有 try/catch、没有栈展开语义、没有「普通错误」和 「异常错误」的区分2。取而代之,错误是一个普通的值,类型是内置接口 error:

type error interface {
    Error() string
}

任何类型,只要实现了 Error() string 方法,就自动是一个 error3。 这意味着错误可以像整数、字符串一样:构造、比较、包装、返回、忽略(但不该忽略)。

2.2 显式传播的固定仪式

每个可能失败的调用后面,跟一段几乎一成不变的检查:

result, err := doSomething()
if err != nil {
    return err
}

这段重复被别的语言用户吐槽最多,而原书说重复是有意的代价: 它保证错误永远不会在你不知情的情况下悄悄穿过调用栈4。 配套的是早返回(early return):出错立刻返回,成功路径不被嵌套压弯:

func process(filename string) error {
    f, err := os.Open(filename)
    if err != nil {
        return fmt.Errorf("opening %s: %w", filename, err)
    }
    defer f.Close()
    // 成功路径在这里,不缩进
    return nil
}

2.3 这套哲学的可靠性账

原书列了五条「错误哲学直接换来的系统稳定性」:失败被立即处理、错误带上下文、 调用方可以包装保留现场、监控系统收到结构化消息、开发者自然写出重试和回退5。 换句话说:Go 把「考虑失败」从品格问题变成了语法问题——不检查错误,代码就 反复在眼前晃,晃到你想出办法为止。

3. error 接口的四种造法

主线例子第 ① 步到第 ④ 步,对应原书四种构造错误的方式6:

① 标准库的错误值。 直接用,如 io.EOF(读到文件结尾)、http.ErrNoCookie。

② 哨兵错误(sentinel error)。 用 errors.New 造一个包级变量, 作为「这个包会出的著名错误」的标记:

var ErrNotFound = errors.New("resource not found")
// 调用方直接比较:
if err == ErrNotFound { /* 专门处理「没找到」 */ }

适合状态有限且明确的场合(没找到、已存在、不可用)。别滥用——哨兵太多, API 会变僵硬7。

③ 自定义错误类型。 错误是个接口,可以背数据。原书的例子:

type ParseError struct {
    Line int
    Msg  string
}

func (e *ParseError) Error() string {
    return fmt.Sprintf("parse error on line %d: %s", e.Line, e.Msg)
}

存了行号和消息,日志里一眼定位;还能让上层按类型决策8。

④ 动态包装:fmt.Errorf + %w。 这是最常用的一种:

return fmt.Errorf("loading configuration: %w", err)

%w(w for wrap)把新消息和原始错误缝在一起:人读到一句完整的话, 机器还能把原始错误剥出来。这就是主线例子的核心机制。

主线例子走一遍:四层包装链

  openConfig()          os.Open 失败:open config.yaml: no such file or directory
      │ 包装:readConfig()      return fmt.Errorf("read config %s: %w", path, err)
      ▼
  loadConfig()          return fmt.Errorf("loading configuration: %w", err)
      ▼
  main()                log.Fatal(err)
  打印出来的一句话:
  loading configuration: read config config.yaml: open config.yaml: no such file or directory
  ── 从外到内三层:谁干的(loading)→ 在哪一步干的(read config)→ 根本原因(no such file)

(具体文件名和错误串按原书示例演示;路径是你自己的。)

为什么 %w 而不是普通拼接: 普通拼接(或用 %v)那句话也能看, 但原始错误就丢了。用 %w,配套两个函数就能找回:

errors.Is(err, os.ErrNotExist)     // err 是/包着「文件不存在」吗?
var pe *ParseError
errors.As(err, &pe)                // err 链里有没有 *ParseError?抽出来
fmt.Println(pe.Line)               // 拿到结构化字段

Is 走「相等或包装」判断,As 走「类型抽取」——两者都沿包装链一层层剥9。 原书明确说:它们取代了脆弱的字符串匹配;判断错误别再 strings.Contains(err.Error(), "not found"), 错误文案一改你的判断就静默失效10。

为什么 Error() 只返回 string? 原书替设计者们回答了:错误要人能读、日志友好、 不带上下文也有意义;需要结构时,自定义类型随便加11。简单是默认,扩展永远开门。

错误即行为。 接口还能挂别的方法。原书例子:一个 RetryableError 多挂一个 Retryable() bool,上层就能「遇到可重试的错误就重试」——错误从「消息」升级成 「决策依据」,而不破坏 error 接口的简单12。

4. panic / defer / recover:受控的崩溃

4.1 panic:程序级失败的信号

panic 让程序沿调用栈向上卷( unwind),沿途跑所有 defer,最后终止—— 除非被 recover 拦下。合法用途很窄:不变量被破坏、逻辑上不可能的状态、 程序员错误(数组越界、nil 解引用也会自动 panic)13。 日常失败路径不用 panic——那是 error 的活。

4.2 defer:怎么退出都执行的清理

defer 把一句调用排到函数退出时执行——正常返回、panic、被 recover,都算:

f, err := os.Open(path)
if err != nil {
    return err
}
defer f.Close()   // 保证跑:return 跑它,panic 也跑它

第 03 章的文件处理已经用上了;原书这里补全它的用途清单:关文件、解锁、刷缓冲、 记退出日志14。多个 defer 按后进先出(LIFO)执行——像一叠盘子,最后放的最先拿。

4.3 recover:在边界把崩溃变回错误

recover 只能在 defer 的函数里调用;它拦下 panic,把 panic 的值(通常是个 字符串或 error)交给你:

func safeExecute(fn func()) (err error) {
    defer func() {
        if r := recover(); r != nil {
            err = fmt.Errorf("execution failed: %v", r)
        }
    }()
    fn()
    return nil
}

典型用法:HTTP 服务器的 handler 外面包一层——单个请求把服务搞 panic, 不能让整个进程陪葬(第 07 章正式用)15。 原书的警告:recover 要有针对性;无差别地吞掉所有 panic 会掩盖严重的逻辑错误, 让调试更难15。

5. 日志:人读、机器也读

log 包默认带时间戳、写到标准错误;log.SetPrefix("AUTH: ") 加前缀, SetFlags(log.Ldate | log.Ltime | log.Lshortfile) 把文件名和行号挂上16。

生产环境更进一步——结构化日志(structured logging):每行一个 JSON 对象, 字段分明,能直接灌进 ELK、Loki、CloudWatch 这类日志平台检索:

type LogEntry struct {
    Level   string `json:"level"`
    Message string `json:"message"`
    Time    string `json:"time"`
}

标准库不强制结构化的格式,社区主流是 Zap、Zerolog、Logrus 三库; 原书的目标句值得记住:日志要同时被人和机器读17。

6. 结构化错误的好味道

原书给了一条错误消息的质检清单——一个合格的错误要说清四件事18:

  1. 什么失败了(what failed);
  2. 为什么失败(why);
  3. 在哪失败(where:哪个文件、哪个用户、哪一行);
  4. 下一步怎么办(what to do next)。

ValidationError{Field, Cause} 那种自定义类型,就是为了把「哪」和「为什么」 变成可程序读取的字段,而不只是散文19。再进一步还能给错误挂:错误码(API 合同)、 关联 ID(分布式系统里把一串日志串起来的编号)、修复建议20。

7. 四个运行时大坑(原书点名)

这一节是全章最实战的部分——四个坑,每个给「症状 → 成因 → 抓法」。

坑一:nil 指针解引用。 对 nil 指针取字段,直接 panic:

var p *Person
fmt.Println(p.Name) // panic: nil pointer dereference

防御靠构造器(保证 new 出来的对象永远可用)和显式的 nil 检查21。

坑二:goroutine 泄漏。 goroutine 永远不退,内存慢慢涨,几天后服务被拖垮。 成因四种:channel 上的 range 没终止信号、无缓冲 channel 上没人收、忘了 close、 等一个永远不会成立的条件22。抓法:runtime.NumGoroutine() 看数量趋势, pprof(第 08 章细讲)看每个 goroutine 卡在哪一行22。

坑三:竞态(race)。 多个 goroutine 无同步地读写同一个变量,结果随机。 抓法是一行命令:

$ go run -race main.go

竞态检测器(-race detector)在运行时盯着每次内存访问,发现两个 goroutine 没同步就碰同一处内存,当场报告。原书称它是 Go 给并行程序的最强调试工具之一23。

坑四:切片陷阱。 append 可能让切片换底层数组(旧引用还在看旧数组); 子切片和原切片共享存储,改一个另一个变;切片传进函数,副作用跟着进24。 ——第 02 章 §5.2 埋的伏笔在这里兑现:看懂共享存储,这四条全是推论。

坑五:死锁。 互斥锁加了忘解(尤其早返回的路径)、两个 goroutine 按不同顺序 拿两把锁互相等、channel 只发不收——程序永久冻结25。静态分析加设计评审预防; -race 和一些死锁检测能帮一半。

7.5 切片陷阱的三个具体形状(配数字)

第 02 章说切片是「窗口」,本章说它有陷阱,这里把三个陷阱各走一遍 (数字为演示):

形状一:append 换了底层数组。 s := make([]int, 0, 2),append 进 1、2; 再 append 进 3——容量不够,Go 悄悄换了个更大的新数组。 如果之前有人用 t := s[:2] 留了个旧窗口,t 还指着旧数组,你改 s[0]=99, t[0] 还是 1。症状:数据「改了一半」。

形状二:子切片改原切片。 a := []int{1,2,3}; b := a[1:3]; b[0]=99—— a 变成 [1,99,3],因为 b 和 a 看着同一个底层数组。症状:在 A 函数改的数, B 函数「莫名其妙」变了。

形状三:函数里的副作用。 切片传进函数是拷贝「窗口描述符」(指针+长度+容量), 不是拷数据——函数里 s[0]=99 会改到调用者的数据。想防住,要么函数注释写清 「会改内容」,要么传值拷贝(第 08 章的「少拷贝」在这要让位给「改不改」的语义)。

三个形状的共同根:窗口共享是特性不是 bug——第 08 章流水线的高性能恰恰 来自不拷数据;出 bug 都是因为「不知道共享、或忘了共享」。

7.6 错误消息质量的三个档位(对着清单评)

第 06 章那张四要素清单(什么、为什么、在哪、下一步)可以用来给错误消息打分:

  • 不及格: return err 裸传——丢了本层上下文,日志里一堆「connection refused」 不知道是谁连谁;
  • 及格: fmt.Errorf("read config: %w", err)——有了「在哪一步」;
  • 优秀: 自定义类型带字段(如 ValidationError{Field, Cause}),机器能按字段 过滤,人能直接看懂。

生产代码的目标是全库「及格」以上;API 边界上、用户看得见的错误,冲「优秀」。

8. 调试工具箱与 AI 辅助(辅线)

8.1 从 printf 到 Delve

  • fmt.Printf("value=%+v\n", v) 仍然是最快的隔离手段(只适合本地);
  • log 带文件行号,适合追控制流;
  • runtime 包:runtime.NumGoroutine() 抓泄漏、runtime.Stack() 抓栈轨迹、 GOMAXPROCS 调 CPU26;
  • panic 输出自带完整栈轨迹——深调试时开发者故意靠它定位27;
  • Delve(dlv):Go 的主调试器,断点、单步、看变量、检查每个 goroutine 的状态—— 最后一条是并发调试的杀手锏。命令行 dlv debug ./cmd/app,也能挂进 VS Code / GoLand28。

8.2 AI 调试的五个场景(原书例)

原书这一节的 AI 例子质量很高,因为每个都给了「AI 的原话」和「改后代码」:

场景一:静默吞错。 data, _ := os.ReadFile(path)——下划线把错误扔了, 调用者还以为读成功了。AI 的原话:「You are discarding the error returned by os.ReadFile. This may lead to nil data being used downstream.」改法:接回 error, 包一层 %w 返回29。 这是全章最要紧的辅线例子:AI 生成代码时最爱顺手写出 _,你审查时最爱漏看 _。

场景二:并发三病同抓。 FetchAll 函数里,AI 一次抓出三个问题:返回的 channel 从不 close(消费方 range 会永远阻塞)、循环里 goroutine 闭包捕获变量有误、HTTP 响应体 没 close。原书评论:静态分析工具未必能三个同时抓到,LLM 的推理补了这个空30。

场景三:解释 panic 轨迹。 贴一段 main.(*Cache).Get(0x0, …),AI 翻成人话: 「方法在 nil 接收者上被调用了——Cache 实例从没被初始化,去找 NewCache() 没被调用的 构造路径。」还顺手给了防御补丁31。

场景四:补上错误包装。 return db.Insert(u) 一行直传,AI 建议包上 save user %s: %w——日志从此可行动32。

场景五:预测性排雷。 LLM 能嗅出「将来的故障模式」:循环里无上限地起 goroutine、 无保护的共享 map、无限等待的网络调用(建议给 http.Client 加 5 秒 Timeout)33。

集成进工作流的做法(原书单):拿 AI 分析失败的测试、把栈轨迹和日志贴给它解释、 合并前让它先做一轮 review34。

判断(我们的,不是书里的): 这五个场景共同的边界是——AI 解释的是模式, 验证的是机制。它能说「这像 goroutine 泄漏」,但「到底是不是」要靠 -race、 NumGoroutine 的数字和 pprof 的栈说话。把 AI 的话当假设、把工具的数字当证据, 这个顺序不能反。如果错,会错在: AI 的解释训练自常见代码,你的代码若走了 不常见的路(自研框架、非常规同步),它会把对的代码也说出一堆「问题」—— 那时浪费的是你的排查时间。

8.3 把原书的 panic 翻译例走到底(辅线的完整一步)

原书给的 panic 轨迹只有六行,但翻译过程值得完整走一遍,因为它示范了 「AI 解释 → 人验证」的完整一步(轨迹为原书示例,行号与地址是演示性的):

  panic: runtime error: invalid memory address or nil pointer dereference
  goroutine 42 [running]:
  app/service.(*OrderService).Process(0x0, …)
      service/order.go:74 +0x45
  app/handler.(*OrderHandler).Handle(…)
      handler/order.go:58
  net/http.HandlerFunc.ServeHTTP(…)

读这种轨迹的固定顺序(从底往上是调用链、从上往下是案发点):

  1. 第一行是死因: nil 指针解引用——某个该是对象的地方,实际是「什么都没指向」。
  2. 第二行是案发现场: (*OrderService).Process 的接收者是 0x0——0x0 就是 nil 的地址写法。 所以不是 Process 内部算错了,是调用它的那个 OrderService 压根没初始化。
  3. 底下几行是案发路径: HTTP 请求 → handler → service——问题不在某个具体请求参数, 而在构造环节:谁该调用 NewOrderService() 而没调。

AI 在这一步的价值是把「0x0 → nil 接收者 → 构造缺失」三步推理一次说完; 人的验证只需要一件事:去 handler/order.go:58 附近找构造点,确认服务真的是 nil, 而不是AI想象出来的。找到之后,修法按第 04 章的次序:构造器保证非 nil、 边界加 nil 检查、给这条路径补一个测试。

8.4 工具箱的选用顺序(什么时候用什么)

症状第一个该拿的工具
程序挂了,有 panic 输出先读栈轨迹(本节),不懂再贴给 AI 翻译
输出时好时坏、随机出错go test -race 或 go run -race
内存缓慢上涨、几天后倒下runtime.NumGoroutine() 看趋势,再 pprof 抓 goroutine 画像
逻辑算错了但程序不崩fmt.Printf 或断点(dlv)
线上间歇性故障结构化日志 + 关联 ID,先把「哪次请求」钉住

顺序的道理:越往上越便宜,越往下越全面。panic 轨迹免费且信息最全; 竞态检测器要专门开;日志体系要平时就建好。新手常反过来——程序崩了先去配日志系统。

9. 作者的判断与证据

硬事实: error 接口定义、%w/errors.Is/errors.As 语义、defer 的 LIFO、 recover 仅限 defer、go run -race 的存在——全部可当场验证391423。 观点: 「重复的检查换来可靠性」「无异常让大型系统可审计」——是 Go 社区 十五年实践凝成的共识式主张,本章未引用任何对照研究45。

10. 边界与局限

  • 错误处理的「噪音」问题没有解法:多层 if err != nil 的样板代码, 本章视之为合理代价,没讨论缓解技巧(如 helper、聚合返回)。
  • 结构化日志只给了 JSON 的方向,三库(Zap/Zerolog/Logrus)没展开对比——选型留给读者。
  • AI 调试没有讨论数据安全:把公司栈轨迹贴给云端 AI 的合规问题,要到第 09 章才补。
  • 错误率的度量、报警阈值(触发报警的临界值)等 SRE 实践只提了一句5,深入是另一本书的事。

11. 可带走的

  1. Go 没有异常;error 是「带 Error() string 方法的接口」,错误是普通值。
  2. 固定仪式:result, err := f(); if err != nil { return ... };早返回保持成功路径不缩进。
  3. fmt.Errorf("...: %w", err) 包装;%w 让 errors.Is(找哨兵)/errors.As(抽类型)可用。
  4. 别用字符串匹配判断错误——用 Is/As。
  5. 哨兵错误管「著名的有限状态」;自定义类型管「要带字段的错误」。
  6. 错误消息四要素:什么、为什么、在哪、下一步怎么办。
  7. defer 保证清理(正常/panic/recover 都跑),多个 defer 后进先出。
  8. panic 只给程序级失败;recover 只在边界(API、goroutine 外层)有针对性使用。
  9. 四大坑:nil 解引用、goroutine 泄漏、竞态(go run -race)、切片共享;加死锁。
  10. 工具箱:printf < log < runtime < dlv;panic 栈轨迹别扔,它能定位。
  11. AI 调试五场景:吞错、并发三病、panic 翻译、补包装、预测性排雷——AI 出假设,工具出证据。
  12. 审 AI 生成代码时,第一眼找下划线 _(被扔掉的错误)。

12. 原文地图

主题原书章原文位置
不用异常的理由4. Error Handling and Debugging in Gotext/14-ch04-4-error-handling-and-debugging-in-go.txt:63(搜「Why Go Rejects Exceptions」)
error 接口定义同上text/14-ch04-4-error-handling-and-debugging-in-go.txt:82(搜「Errors as Values」)text/14-ch04-4-error-handling-and-debugging-in-go.txt:172(搜「The Error Interface」)
显式传播与早返回同上text/14-ch04-4-error-handling-and-debugging-in-go.txt:98(搜「Explicit Error Propagation」)text/14-ch04-4-error-handling-and-debugging-in-go.txt:327(搜「early return」)
哨兵错误同上text/14-ch04-4-error-handling-and-debugging-in-go.txt:192(搜「stable, reusable error value」)
自定义错误类型同上text/14-ch04-4-error-handling-and-debugging-in-go.txt:203(搜「Custom Error Types」)
%w 包装与 Is/As同上text/14-ch04-4-error-handling-and-debugging-in-go.txt:236(搜「allows error wrapping」)text/14-ch04-4-error-handling-and-debugging-in-go.txt:246(搜「two key functions」)
为什么 Error() 返回 string同上text/14-ch04-4-error-handling-and-debugging-in-go.txt:262(搜「Strings for Error Messages」)
错误即行为同上text/14-ch04-4-error-handling-and-debugging-in-go.txt:274(搜「Errors as Behaviour」)
panic / defer / recover同上text/14-ch04-4-error-handling-and-debugging-in-go.txt:31(搜「Signalling an Unexpected」)、:439(搜「Ensuring Cleanup」)、:465(搜「Regaining Control」)
结构化日志同上text/14-ch04-4-error-handling-and-debugging-in-go.txt:525(搜「Logging for Clarity」)text/14-ch04-4-error-handling-and-debugging-in-go.txt:542(搜「observability platforms」)
错误消息四要素同上text/14-ch04-4-error-handling-and-debugging-in-go.txt:578(搜「What failed」)
四个运行时坑同上text/14-ch04-4-error-handling-and-debugging-in-go.txt:606(搜「Common Runtime Pitfalls」);-race 见 :628
runtime 与 Delve同上text/14-ch04-4-error-handling-and-debugging-in-go.txt:657(搜「runtime package」)text/14-ch04-4-error-handling-and-debugging-in-go.txt:669(搜「Delve」)
AI 调试五场景同上text/14-ch04-4-error-handling-and-debugging-in-go.txt:694(搜「Silent Error Ignoring」)、:723(搜「Goroutine Leak」)、:772(搜「Interpreting a Panic」)、text/14-ch04-4-error-handling-and-debugging-in-go.txt:803(搜「AI-Recommended Version」)、:869(搜「Predictive Debugging」)

Footnotes

  1. 出处:「4. Error Handling and Debugging in Go」第 63–80 段(text/14-ch04-4-error-handling-and-debugging-in-go.txt:63,搜「Why Go Rejects Exceptions」)。原书列举隐藏控制流的代价:「can make it difficult to reason about a program's behavior without scanning the entire call tree」(见 :67)。 ↩

  2. 出处:同章第 70–73 段(text/14-ch04-4-error-handling-and-debugging-in-go.txt:71,搜「No try/catch blocks」)。 ↩

  3. 出处:同章第 82–96 段(text/14-ch04-4-error-handling-and-debugging-in-go.txt:82,搜「Errors as Values」;text/14-ch04-4-error-handling-and-debugging-in-go.txt:84)与第 172–186 段(text/14-ch04-4-error-handling-and-debugging-in-go.txt:172,搜「The Error Interface」)。 ↩ ↩2

  4. 出处:同章第 98–114 段(text/14-ch04-4-error-handling-and-debugging-in-go.txt:98,搜「Explicit Error Propagation」)。「the repetition is a deliberate trade-off」为原文明写(:105)。 ↩ ↩2

  5. 出处:同章第 147–160 段(text/14-ch04-4-error-handling-and-debugging-in-go.txt:147,搜「Impact on Software Reliability」)。 ↩ ↩2 ↩3

  6. 出处:同章第 172–260 段(text/14-ch04-4-error-handling-and-debugging-in-go.txt:162,搜「Understanding the Error Type」)。 ↩

  7. 出处:同章第 359–368 段(text/14-ch04-4-error-handling-and-debugging-in-go.txt:360,搜「predefined error variables」)。 ↩

  8. 出处:同章第 203–223 段(text/14-ch04-4-error-handling-and-debugging-in-go.txt:203,搜「Custom Error Types」;ParseError 定义见 :205)。 ↩

  9. 出处:同章第 233–260 段(text/14-ch04-4-error-handling-and-debugging-in-go.txt:236,搜「allows error wrapping」;两个函数的语义见 见 text/14-ch04-4-error-handling-and-debugging-in-go.txt:246,搜「two key functions」)。 ↩ ↩2

  10. 出处:同章第 369–384 段(text/14-ch04-4-error-handling-and-debugging-in-go.txt:369,搜「precise inspection」)。「fragile string matching」为原文明写(:382)。 ↩

  11. 出处:同章第 262–272 段(text/14-ch04-4-error-handling-and-debugging-in-go.txt:262,搜「Strings for Error Messages」)。 ↩

  12. 出处:同章第 274–292 段(text/14-ch04-4-error-handling-and-debugging-in-go.txt:274,搜「Errors as Behaviour」;RetryableError 见 :277)。 ↩

  13. 出处:同章第 416–437 段(text/14-ch04-4-error-handling-and-debugging-in-go.txt:31,搜「Signalling an Unexpected Failure」)。 ↩

  14. 出处:同章第 439–464 段(text/14-ch04-4-error-handling-and-debugging-in-go.txt:439,搜「Ensuring Cleanup」;LIFO 见 :463)。 ↩ ↩2

  15. 出处:同章第 465–490 段(text/14-ch04-4-error-handling-and-debugging-in-go.txt:465,搜「Recover: Regaining Control」;「obscure severe logic errors」见 :482)。 ↩ ↩2

  16. 出处:同章第 525–540 段(text/14-ch04-4-error-handling-and-debugging-in-go.txt:525,搜「Logging for Clarity」;SetPrefix/SetFlags 示例见 :536)。 ↩

  17. 出处:同章第 541–560 段(text/14-ch04-4-error-handling-and-debugging-in-go.txt:542,搜「observability platforms」;三库见 :557)。 ↩

  18. 出处:同章第 576–581 段(text/14-ch04-4-error-handling-and-debugging-in-go.txt:578,搜「What failed」)。 ↩

  19. 出处:同章第 582–597 段(text/14-ch04-4-error-handling-and-debugging-in-go.txt:584,搜「Field string」)。 ↩

  20. 出处:同章第 598–604 段(text/14-ch04-4-error-handling-and-debugging-in-go.txt:598,搜「Annotating Errors」;correlation IDs 见 :602)。 ↩

  21. 出处:同章第 610–616 段(text/14-ch04-4-error-handling-and-debugging-in-go.txt:610,搜「Nil Pointer Dereferences」)。 ↩

  22. 出处:同章第 617–625 段(text/14-ch04-4-error-handling-and-debugging-in-go.txt:617,搜「Goroutine Leaks」;成因四条见 :620)。 ↩ ↩2

  23. 出处:同章第 626–632 段(text/14-ch04-4-error-handling-and-debugging-in-go.txt:626,搜「Race Conditions」;go run -race 见 :630)。 ↩ ↩2

  24. 出处:同章第 633–639 段(text/14-ch04-4-error-handling-and-debugging-in-go.txt:633,搜「Slice Pitfalls」)。 ↩

  25. 出处:同章第 640–646 段(text/14-ch04-4-error-handling-and-debugging-in-go.txt:640,搜「Deadlocks」)。 ↩

  26. 出处:同章第 657–663 段(text/14-ch04-4-error-handling-and-debugging-in-go.txt:657,搜「runtime package」)。 ↩

  27. 出处:同章第 664–668 段(text/14-ch04-4-error-handling-and-debugging-in-go.txt:664,搜「stack traces」)。 ↩

  28. 出处:同章第 669–676 段(text/14-ch04-4-error-handling-and-debugging-in-go.txt:669,搜「Delve」)。 ↩

  29. 出处:同章第 694–717 段(text/14-ch04-4-error-handling-and-debugging-in-go.txt:694,搜「Silent Error Ignoring」;AI 原话见 :705)。 ↩

  30. 出处:同章第 723–767 段(text/14-ch04-4-error-handling-and-debugging-in-go.txt:723,搜「Goroutine Leak」;「Static analysis tools alone may not catch all the three」见 :766)。 ↩

  31. 出处:同章第 769–793 段(text/14-ch04-4-error-handling-and-debugging-in-go.txt:769,搜「Panic Analysis」;AI 解释见 :779)。 ↩

  32. 出处:同章第 795–811 段(text/14-ch04-4-error-handling-and-debugging-in-go.txt:795,搜「Error Wrapping」;SaveUser 例见 :800)。 ↩

  33. 出处:同章第 869–888 段(text/14-ch04-4-error-handling-and-debugging-in-go.txt:869,搜「Predictive Debugging」;Timeout 建议见 :879)。 ↩

  34. 出处:同章第 890–899 段(text/14-ch04-4-error-handling-and-debugging-in-go.txt:890,搜「Integrating AI-Assisted」)。 ↩

函数、包与模块化 — 从一堆函数到一座有层次的工程

Previous Page

Go 并发 — goroutine、channel 与同步的一整张地图

Next Page

On this page

错误处理与调试 — Go 为什么不要异常,以及崩了怎么办1. 顶层全景:三条失败路径2. 核心原理:错误是值,不是控制流2.1 解决什么问题:异常的隐藏控制流2.2 显式传播的固定仪式2.3 这套哲学的可靠性账3. error 接口的四种造法主线例子走一遍:四层包装链4. panic / defer / recover:受控的崩溃4.1 panic:程序级失败的信号4.2 defer:怎么退出都执行的清理4.3 recover:在边界把崩溃变回错误5. 日志:人读、机器也读6. 结构化错误的好味道7. 四个运行时大坑(原书点名)7.5 切片陷阱的三个具体形状(配数字)7.6 错误消息质量的三个档位(对着清单评)8. 调试工具箱与 AI 辅助(辅线)8.1 从 printf 到 Delve8.2 AI 调试的五个场景(原书例)8.3 把原书的 panic 翻译例走到底(辅线的完整一步)8.4 工具箱的选用顺序(什么时候用什么)9. 作者的判断与证据10. 边界与局限11. 可带走的12. 原文地图Footnotes