错误处理

本章导读

前面九章里我们已经"偶遇"过不少错误：除零、断言、as 失败、数组越界。它们的下场并不相同——有的可以被捕获处理，有的直接终结进程。本章把错误处理正式讲透：try/catch/finally 捕获与清理、throw 抛出与分类、error 对象、assert 断言，以及最重要的一课——哪些错误接得住，哪些接不住。

xlang 的错误模型刻意简单：用户侧只抛字符串描述，运行时包装成统一的 error 对象，按"分类"匹配 catch。学完本章，你写的程序将在意外面前保持体面。

10.1 try/catch/finally

三段式结构：try 包住可能出错的代码，catch 接住错误，finally 无论成败都执行：

try
    throw "boom"
catch e
    println(e.kind)       // Error
    println(e.message)    // boom
finally
    println("done")
end

允许的组合：try/catch、try/finally、try/catch/finally——catch 和 finally 至少有一个。finally 的语义是"收尾必做"：不管 try 块正常结束还是抛出异常，finally 都执行；实测即便在 try/catch 里 return，finally 也会先跑完再放行（见 10.5 节）。

catch e 声明的变量 e 只在 catch 块内有效，类型是 error（下一节详述）。catch 变量名必须写出——没有省略变量名的"裸 catch"写法。

10.2 throw 与错误分类

抛出错误用 throw，两种形态：

throw "boom"                      // 形态一：字符串，分类为 Error
throw ValueError "bad value"     // 形态二：指定分类 + 字符串

形态一中，throw 后面是一个 string 表达式，运行时包装为 kind = "Error" 的错误对象。形态二在字符串前加内置错误分类名，让错误带上精确的种类——调用方就能按种类分别处理（10.4 节）。

实测可用的内置分类包括 Error、RuntimeError、ValueError、FileError、ArithmeticError、ZeroDivisionError、OverflowError、AssertionError 等。写不存在的分类名，编译期直接拒绝：

两条限制：抛出的描述必须是能静态确认的 string——var 动态字符串不能进 throw；分类名必须是语言预定义的分类，用户暂不能自定义新分类（想表达业务错误，用 ValueError 加有辨识度的 message 是惯例）。

try
    throw ValueError "age cannot be negative"
catch e
    println(e.kind + " / " + e.message)
end

10.3 error 对象

catch 到的 e 是 error 类型对象。当前版本可用的字段就四个——多访问一个都会被编译器点名：

报错信息里还透露了一个 file 字段——实测主脚本中它为空字符串（抛出位置就是当前文件），跨文件场景才有意义。设计文档规划的 cause、stack、code 等 richer 字段属于长期目标，当前不可用。

日常用法：kind 用于分流，message 用于展示，line/column 用于日志定位。

10.4 分类 catch 与匹配顺序

catch 可以带分类：catch 分类名 e 只接这一类错误；多个 catch 分支按源码顺序匹配，命中即止；兜底的无分类 catch e 必须放在最后：

int z = 0
try
    int x = 1 / z
catch ValueError e
    println("值错误")
catch ArithmeticError e
    println("算术错误: " + e.kind)     // 命中这里
catch e
    println("其他: " + e.kind)
end

这个例子同时展示了分类继承：除零产生的 ZeroDivisionError 是 ArithmeticError 的子分类，所以被第二个分支接住；而 e.kind 报告的仍是真实种类 "ZeroDivisionError"。当前继承层级：

工程推论：catch 分支从具体到一般排列——先 ZeroDivisionError，再 ArithmeticError，最后兜底 catch e。顺序写反，具体分支就成永远到不了的死代码。

10.5 异常传播与重新抛出

函数内抛出的异常，如果没被本函数捕获，就沿调用链向上传播，直到遇到能接住它的 catch：

func div(int a, int b) as int
    return a / b          // b 为 0 时在此抛出
end

try
    println(string(div(10, 0)))
catch e
    println("caught in main: " + e.kind)
end

catch 块里写空 throw（不带任何表达式）表示"处理不了，原样再抛"——kind、message、位置全部保留：

func work()
    try
        int z = 0
        int x = 1 / z
    catch e
        println("log: " + e.kind)    // 记日志
        throw                       // 原样上抛
    end
end

try
    work()
catch e
    println("outer: " + e.kind + " / " + e.message)
end

"记日志 + 空 throw"是中间层的标准姿势：既不隐瞒问题，也不放弃现场。想在中间层转换错误语义也可以——catch 里抛一个新分类的错误（如把 ZeroDivisionError 转成 ValueError），但原始错误不会自动附带，必要时把 e.message 拼进新消息。

一路无人接住会怎样？异常冲到顶层，进程打印诊断并以退出码 1 终止：

格式：文件:行:列: uncaught 分类: 描述。位置信息精确到抛出点，调试体验相当友好。

10.6 assert 断言

断言声明"此处必须为真"的程序假设，两种形态：

assert count > 0                          // 形态一：仅条件
assert path != "", "path is empty"       // 形态二：条件 + 说明

断言失败抛出 AssertionError——它是可捕获的异常，不是 fatal：

try
    assert 1 > 2
catch e
    println(e.kind + " / " + e.message)
end
try
    assert 1 > 2, "one must exceed two"
catch e
    println(e.kind + " / " + e.message)
end

无消息时默认描述是 "assert failed"，带消息时就是你的原文。条件必须是 bool（assert 1 报 [sem] assert 条件必须是 bool），消息必须是静态可确认的 string。

断言的使用哲学：assert 检查"绝不应该发生"的内部不变量，throw 报告"可能会发生"的外部错误。参数校验用 throw（调用方可能传错），内部状态自检用 assert（错了说明自己有 bug）。

10.7 异常 vs fatal 的边界

把前十章的实测结果汇总成一张表——这是本章最需要背下来的内容：

设计逻辑（回链第 7 章拾遗 3）：异常给"调用方可能合理处理"的错误，fatal 给"继续执行只会扩大破坏"的 bug。数组越界和 as 失败意味着程序逻辑已错，xlang 选择立即终止而不是让你在错误状态上继续裸奔。工程纪律随之清晰：

• 越界防护靠事前判断（长度检查、9.7 节的 in），不靠 try；
• as 之前必有 is（第 8 章模式）；
• try/catch 留给真正的可恢复错误：IO、解析、业务校验。

深入细节

⚠️ 常见错误

以下报错全部来自真实编译器输出（文件路径已缩短）。

本章小结

复习题

编程练习