企业官网建设流程全解析

• 编程语言
• 语言运行时
• 编译器

Wren 是一门小型、快速、基于类的并发脚本语言，其错误处理机制别具一格：它没有传统语言的 try/catch 异常体系，而是将"错误"划分为语法错误、运行时错误与失败（failure）三个层次，并借助轻量级协程 Fiber 完成运行时错误的捕获与传播。本文以官方文档 doc/site/error-handling.markdown 为骨架，结合 src/vm/wren_core.wren、src/vm/wren_vm.c 的底层实现与 test/core/fiber 下的大量测试用例，完整讲解 Wren 中每一类错误的含义、表现与处理方式。读完本文，你将掌握 Wren 的报错格式、Fiber.try()/Fiber.abort()/fiber.error的完整用法，以及"用返回值表达失败"的 Wren 惯用设计。

错误的三种层次

Wren 官方文档将错误明确划分为三个层次，理解这个分层是掌握 Wren 错误处理的前提：

其中"失败"并非语言层面的报错，而是一种约定俗成的设计模式，本文最后一节会详细展开。

语法错误：编译期即时报错

语法错误是开发者最先遇到的错误类型，包括代码不符合语言文法的"硬"语法错误，例如：

1 + * 2

Wren 在尝试读取代码时立即检测到这类问题，并给出友好的错误信息：

[main line 1] Error on '*': Unexpected token for expression.

错误信息采用统一格式：[模块名 行号] Error on '出错位置': 具体原因，让开发者能直接定位到出错的文件、行号与 token。

作用域级别的"语义"错误

一些更具"语义"色彩的编译期错误也归入此类，比如使用未定义的变量，或在同一作用域内重复声明同名变量。以下代码：

var a = "once" var a = "twice"

Wren 会报告：

[main line 2] Error on 'a': Top-level variable is already defined.

值得强调的是：Wren 会在执行任何代码之前完成全部编译期检查。也就是说，只要程序开始运行，你就可以确定代码中不存在语法或作用域层面的错误。与某些脚本语言"边执行边发现"的做法不同，Wren 倾向于在尽可能早的阶段暴露问题。

从实现角度看，这类检查发生在编译器（src/vm/wren_compiler.c）的变量解析阶段：源码先被完整编译为字节码，编译过程中同步进行作用域与符号检查，只有编译成功才会进入解释执行阶段。这也解释了为何 Wren 敢于承诺"运行即无语法错误"。

运行时错误：VM 无法执行的操作

即使消除了所有编译期错误，程序仍可能在运行时遭遇无法静态检测的问题，这类错误统称为"运行时错误"。它们大多由 VM 自身抛出，源于代码尝试执行 VM 无法完成的操作。

最常见的两种运行时错误

方法不存在（method not found）。当你对某个对象调用一个方法，而该对象的类及其全部父类都没有定义此方法时，Wren 无能为力：

class Foo { construct new() {} } var foo = Foo.new() foo.someRandomMethod

运行结果：

Foo does not implement method 'someRandomMethod'.

参数类型错误（wrong argument type）。例如列表的索引必须是数字，传入其他类型就是错误：

var list = ["a", "b", "c"] list["1"]

程序随即退出并输出：

Subscript must be a number or a range. [main line 2] in (script)

第二行便是调用栈追踪：它指出错误发生在哪一行、位于哪个方法调用链中。除了上述两种，运行时错误还包括列表越界、调用函数时参数个数错误等。

错误即中止：不"带病运行"

与某些语言在运行时错误后继续执行不同，Wren 一旦发生运行时错误就停止执行当前代码。因为运行时错误意味着代码存在 bug，Wren 希望立即引起你的注意，为此它会打印完整的调用栈，标明错误发生位置以及所有引出该错误的调用链。设计哲学是：宁可立即中止，也不要让错误悄悄污染后续逻辑。

底层机制：runtimeError 沿 Fiber 链传播

在 VM 实现中，运行时错误的传播路径非常清晰。当解释器遇到错误时，会调用 src/vm/wren_vm.c 中的runtimeError()函数。该函数从当前 Fiber 出发，沿着caller指针逐级向上遍历整个 Fiber 调用链：

• 沿途每一个 Fiber 都会被赋予同一个错误（current->error = error）；
• 如果某个 Fiber 是被try方式调用的（状态为FIBER_TRY），则停止传播，让try方法返回错误消息；
• 否则继续向上解链（current->caller = NULL）；
• 若一直走到链头都无人"接住"错误，则调用wrenDebugPrintStackTrace(vm)打印调用栈并停止整个 VM。

这段代码同时印证了本文后续要讲的"错误会沿着 Fiber 调用链寻找try"这一行为。

用 Fiber 处理运行时错误：try() 与 error

为了保持语言简洁，Wren 没有异常处理机制（exception handling），而是利用 Fiber 来承担错误处理职责（Fiber 的基础概念见 doc/site/concurrency.markdown）。当一个运行时错误发生时，当前 Fiber 被中止；正常情况下，Wren 会沿着调用链逐级中止所有调用过它的 Fiber，一路追溯到主 Fiber，然后退出 VM。

try()：把错误"接住"

但如果你用try方法运行一个 Fiber，情况就不同了：如果被调用的 Fiber 内部发生运行时错误，错误会被捕获，并由try方法以字符串形式返回。

var fiber = Fiber.new { 123.badMethod } var error = fiber.try() System.print("Caught error: " + error)

输出：

Caught error: Num does not implement method 'badMethod'.

注意此处123的类在 Wren 中显示为Num，这与 src/vm/wren_core.wren 中class Num {}的类名定义一致。被中止的 Fiber 之后不能再被使用，但其他 Fiber 可以照常运行。

try方法还支持传入参数，用于给首次启动的 Fiber 函数传值（函数可带 0 或 1 个参数）：

var fiber = Fiber.new {|value| value.badMethod } var error = fiber.try("just a string") System.print("Caught error: " + error)

关于try的边界行为，test/core/fiber 中的测试给出了精确约定：

• fiber.try()成功捕获错误后再次try()同一个 Fiber，会报Cannot try an aborted fiber.（见 try_error.wren）；
• 对已经正常运行完毕的 Fiber 调用try()，会报Cannot try a finished fiber.（见 try_done.wren）；
• 被try捕获错误后，再对它call()会报Cannot call an aborted fiber.（见 call_error.wren）。

error 属性：从 Fiber 对象上读取错误

当一个 Fiber 因运行时错误被中止后，你还可以通过该 Fiber 的error属性取得错误消息。延续上面的例子：

System.print(fiber.error)

同样输出：

Num does not implement method 'badMethod'.

在 test/core/fiber/error.wren 中可以看到error属性的完整语义：未出错前fiber.error为null；try()捕获错误之后，fiber.error才被填充为错误消息。也就是说，error是"中止后"才有效的信息来源，与try()的返回值互补。

沿调用链传播：try 可以隔层接住错误

如果你有一整条 Fiber 调用链，且某处发生运行时错误，错误会沿链逐级向上"寻找"try调用。因此，即使错误产生于被try调用的 Fiber 所间接调用的更深层 Fiber 中，try同样能捕获它。

test/core/fiber/try_through_call.wren 用一个五层 Fiber 链完整演示了这一行为：

var fiber1 = Fiber.new { Fiber.abort("Abort!") } var fiber2 = Fiber.new { fiber1.call() } var fiber3 = Fiber.new { fiber2.call() } var fiber4 = Fiber.new { fiber3.try() } var fiber5 = Fiber.new { fiber4.call() } fiber5.call()

测试断言显示：fiber1、fiber2、fiber3都被同一错误中止（fiber.error均为"Abort!"），而fiber4（执行try的 Fiber）和fiber5的error为null，程序在try处成功接住错误后继续执行。这正是 src/vm/wren_vm.c 中"沿途所有 Fiber 都被中止，直到命中FIBER_TRY状态"这一逻辑的运行时体现。

主动制造运行时错误：Fiber.abort()

大多数运行时错误由 VM 内部产生，但你也可以主动制造运行时错误——调用Fiber类上的静态方法abort()：

Fiber.abort("Something bad happened")

必须传入错误消息，且必须是字符串；当传入的消息为null时，不会引发任何运行时错误。

两个边界情况都有对应的测试佐证：

• test/core/fiber/abort.wren：Fiber.abort("Error message.")后，fiber.try()返回"Error message."，fiber.isDone为true，fiber.error也填充为同一消息——可见abort引发的错误与 VM 原生运行时错误走的是同一条捕获通路；
• test/core/fiber/abort_null.wren：Fiber.abort(null)不会中止 Fiber，后续代码继续执行（打印"get here"），Fiber 甚至可以照常yield，fiber.isDone为false、fiber.error为null。

有趣的是，测试 abort_not_string.wren 显示Fiber.abort(123)传入非字符串时，错误消息会原样保留为数字123并被try()返回。虽然官方文档明确要求"必须传入字符串"，但从实现与测试看，传入非字符串并不会触发类型错误，而是把该值当作错误消息传递。

abort()在核心库中被大量用作"参数校验"手段。查看 src/vm/wren_core.wren 可以看到典型模式：

skip(count) { if (!(count is Num) || !count.isInteger || count < 0) { Fiber.abort("Count must be a non-negative integer.") } ... }

类似的参数校验散落在String.split（"Delimiter must be a non-empty string."）、List.sort（"Comparer must be a function."）、Sequence.reduce（"Can't reduce an empty sequence."）等核心方法中，可选模块 src/optional/wren_opt_random.wren（如 "Sequence cannot be empty."）与 src/optional/wren_opt_meta.wren（如 "Module name must be a string."）也沿用了同一约定。这为自定义库实现参数校验提供了标准范式。

失败（Failure）：用返回值表达可预期的错误

最后一个层次是最高层的"失败"。以上所有错误都指向bug——代码本身写错了；但有些"错误"意味着代码只是因为不可预见的原因没能完成任务，这类情况本文称之为 failure（失败）。

考虑一个从用户输入解析数字的程序：很多字符串并非合法数字，解析必然可能失败。程序唯一能阻止这种失败的方式是在解析前先校验字符串，但"校验一个字符串是不是数字"与"解析它"几乎是同一件事——你无法在不实现解析逻辑的情况下预先判断成败。对于这种"失败必然会发生、且程序确实想要处理它"的场景，Fiber 与try()过于粗粒度，并不适用。

约定：成功返回结果，失败返回 null

Wren 的答案是：这些操作通过"返回"某种错误指示来表达失败。例如，一个解析数字的方法可以在成功时返回数字、在解析失败时返回null。由于 Wren 是动态类型语言，一个方法返回不同类型值的做法既简单又自然。

这一模式在核心库中有最直接的官方范例——Num.fromString()。查看测试 test/core/number/from_string.wren：

System.print(Num.fromString("123") == 123) // expect: true System.print(Num.fromString(" 12 ") == 12) // expect: true // Test some non-number literals and ensure they return null. System.print(Num.fromString("test1") == null) // expect: true System.print(Num.fromString("") == null) // expect: true System.print(Num.fromString("prefix1.2") == null) // expect: true System.print(Num.fromString("1.2suffix") == null) // expect: true

成功时返回数字、失败时返回null——调用方用一行判断即可区分两种结果，无需依赖异常机制。这也解释了为什么Num.fromString对非法输入不抛错：它属于"失败"语义，而非"bug"语义。相比之下，如果传入的参数本身类型不对（如Num.fromString(1)），那属于 bug，会触发运行时错误Argument must be a string.（见 from_string_not_string.wren）；如果数字字面量超出范围，则报Number literal is too large.（见 from_string_too_large.wren）。三者对比可以清晰看出 Wren 对"失败"与"错误"的边界划分。

与 Fiber 捕获的取舍

在 doc/site/modularity.markdown 所倡导的模块化实践中，这一模式同样适用：跨模块传递"可能失败"的结果时，返回null或其他哨兵值比抛错更轻量、更易组合。而try()/abort()更适合处理"异常情况下才发生的真正错误"。

实践总结：Wren 错误处理的四条规则

1. 编译期错误（语法、作用域）不可捕获：Wren 在执行前完成全部静态检查，运行即无语法错误；
2. 运行时错误即中止：不"带病运行"，用 Fiber 中止 + 调用栈追踪暴露 bug；
3. 捕获用try()，查询用error：fiber.try()返回错误消息字符串，被中止的 Fiber 不可复用，fiber.error在出错后填充；错误会沿 Fiber 链传播直到命中try；
4. 主动报错用Fiber.abort(message)：消息须为字符串，null表示不报错；
5. 可预期的失败用返回值表达：如Num.fromString成功返回数字、失败返回null，不要滥用 Fiber 异常机制。

完整的 Fiber API 细节（call、yield、transfer、transferError等）可进一步参阅 doc/site/modules/core/fiber.markdown，其测试覆盖集中在 test/core/fiber，官方指南中的姊妹篇 并发与 Fiber 与 模块化 也值得一并阅读。

• 编程语言
• 语言运行时
• 编译器