WASM 异常处理与栈切换提案：try_table、suspend/resume 与异步运行时

语言的异常需求：
□ C++：try/catch/throw（RAII 与栈展开）
□ Rust：panic（默认 abort，可 unwind）、Result
□ Java/C#/Kotlin：checked exceptions（WasmGC 语言尤其依赖）

WASM 视角：
□ 异常 = 一种「非局部控制流」——从任意深度跳回处理点
□ 编译器需要表达「可能抛、在哪接住、栈怎么展开」

方案 1：禁用异常（panic=abort / -fno-exceptions）
  → 程序遇到错误直接终止，无法优雅处理
  → 运行时崩，不能 catch

方案 2：返回码 + 手动检查
  → 每个可能失败的函数返回「结果 + 错误」
  → 调用方必须逐层检查 → 样板代码爆炸
  → 性能：每条路径都要分支

方案 3：自己用线性内存模拟「异常表 + 长跳转」
  → 复杂、易错、难调试
  → 编译器各搞各的，无法互操作

核心机制：
□ 标签（tags）：像「异常类型」，可携带值（tag + 负载）
□ throw：抛出「标签 + 值」→ 在调用栈中查找匹配的 catch
□ 捕获：把标签值解包，执行处理代码
□ 栈展开：抛出时跳过中间帧（类似语言的异常传播）

;; 声明异常标签
(tag $oom (param i32))     ;; 携带一个 i32（错误码）

;; 抛出
i32.const 42
throw $oom                  ;; 抛出 $oom 标签 + 值 42

与语言映射：
C++ throw → WASM throw + tag（运行时把异常类型映射成标签）
Rust panic → 默认 abort（无 unwind）或 unwind 用异常标签
JS → host 异常可以跨边界传给 WASM（见第 5 节）

;; 捕获模式：在一个块里尝试执行，异常时跳到 catch
block $try
  ;; ... 可能抛出的代码 ...
  ;; 正常路径结束
end

;; 更完整的 try_table 模式（见下节）
try_table $catch_oom
  i32.const 1
  call $may_throw          ;; 内部可能 throw $oom
end
$catch_oom:
  ;; 异常被接住：栈上是异常值（i32 错误码）
  ;; 处理...

br_on_exn 语义：
标签匹配 → 分支到目标，栈上保留「标签值」
标签不匹配 → 继续传播（跳过）
  → 编译器用它实现「catch 按类型分流」

;; try_table：块内异常按标签分派
try_table (catch $oom $handler_oom) (catch_all $handler_any)
  call $risky_op
end

;; 跳到 $handler_oom：栈上是 $oom 的载荷
$handler_oom:
  ;; 处理 OOM，恢复执行
$handler_any:
  ;; 兜底处理

跨宿主分派（host ↔ WASM）：
□ JS 抛异常 → WASM 的 try_table 可以接住（类型化传递）
□ WASM throw → 宿主 JS 可以 catch（转成 JS 异常/值）
  → 异常跨边界可双向传递，不再被「卡在模块里」

Rust 的两条路：
□ panic = "abort"：异常直接 trap，体积小、简单
□ panic = "unwind"：用异常标签实现 unwinding（提案支持后）
  → 可 catch_unwind，但体积/性能有代价

核心指令：
suspend：挂起当前栈，跳到 host 提供的 continuation（记录恢复点）
resume：从保存的恢复点继续执行（栈被恢复）

模型：
□ 挂起点 = 一个「恢复点」，保存调用栈状态
□ 挂起时可以「换到另一条栈」（coroutine 切换）
□ 栈迁移：把当前栈复制/移动到新栈 → 真正的协程

关键提案（Phase 2+）：swift / suspend / resume，配合：
□ stack guards（栈边界保护）
□ 作用域（scoped continuations，限制恢复次数）

;; 伪示意：suspend 到 host 的入口
(func $yield (param i32)
  suspend $entry            ;; 挂起，栈上带上 payload 给 host
  ;; host resume 后从这里继续
  )

JSPI 做什么：
□ 允许同步 WASM 函数调用「会返回 Promise 的 JS 函数」
□ WASM 侧看起来是同步返回（内部挂起、等 Promise、再恢复）
□ 消除「async 传染」：不用把整个调用链改成 async

原理：由 JS 引擎（V8）自动做挂起/恢复的桥接
  → 编译期/运行期的「隐式栈切换」

// JSPI（示意）：同步调用异步 fetch
const fn = WebAssembly.activateSuspending(fetchFn);   // 包装
const result = fn();   // 同步返回，内部等 Promise

与栈切换提案的关系：
□ JSPI = 面向 JS 的先行实现（engine 内建）
□ Stack Switching = 通用的底层能力（编译器/运行时自由使用）
  → JSPI 可视为「栈切换的一个特定用法」

应用场景：
□ 异步 I/O：同步风格读写，I/O 等待时挂起、事件到达恢复
□ 生成器/迭代器：next() 挂起、yield 恢复
□ 协作式多任务：一个线程里调度多个「协程」，共享栈池
□ 事件循环集成：WASM 协程与 JS 事件循环互相唤醒
□ 游戏/状态机：可恢复的状态转移

成本与限制：
□ 栈迁移：复制/切换栈有开销（栈越大越贵）
□ 栈大小：挂起栈要保留，内存占用增加
□ 需要显式标记：编译器必须知道「哪个调用可能挂起」（否则栈不能迁移）
□ 与线程模型交互：多线程 + 栈切换的组合仍在演进（见 /wasm-multithreading-sharedarraybuffer/）