# 语言哲学：错误处理的两种流派与边界设计
学习目标：从端口解析与错误传播示例推导“显式值返回”与“异常中断机制”在可见性、传播链与恢复策略上的根本取舍。
前置阅读：字符串转端口号、表达与传播失败 与 区分失败原因。
# 两组完全不同的调用方心智
在字符串转端口号中，面对外部非法文本（如 "65536"），各语言向调用方暴露的接口形态呈现出鲜明的分野：
- 第一流派（显式值返回）：Rust 的
Result<u16, &'static str>、Go 的(uint16, error)、C++ 的std::optional<uint16_t>。 - 第二流派（异常抛出）：Java 的
throw new IllegalArgumentException、Python 的raise ValueError、JavaScript 的throw new RangeError。
这并不是单纯的语法偏好，而是对**“调用方是否必须在每一步直面失败”**这一哲学命题的不同回答。
# 显式结果流派的取舍
# 机制事实
- Go 要求显式多值返回
(val, err)。语言不提供自动传播机制，调用者必须写出if err != nil { return ..., err }。 - Rust 将成功与失败建模为代数类型
Result<T, E>，编译器对未消费的Result会给出#[must_use]编译警告；通过?操作符将失败传播语法糖化。
# 设计分析
- 收益（可见性极高）：调用方在阅读函数签名时，无需翻阅底层源码或文档，就能确定该函数一定会失败、可能以什么类型失败。不存在隐藏的不可见跳转。
- 成本（代码结构碎裂）：如果一连串操作每个都需要校验，Go 代码中会充斥大量的 3 行错误样板；而在没有语言级支持的系统语言中，返回值处理会极大稀释核心业务逻辑的注意力。
# 异常机制的优势与失控陷阱
# 机制事实
- Python、Java、JavaScript 的异常机制打破了常规的代码自上而下的线性时序。一旦
throw或raise，控制流立即沿调用栈向上跳转，直到最近的一个catch块捕获。
# 设计分析
- 收益（成功路径一目了然）：核心业务代码可以保持连贯的书写风格，无需层层手动向上传递错误对象，所有的 I/O 错误和参数校验错误均可交由最外层集中处理。
- 成本（隐蔽控制流与吞异常）：
- 隐蔽跳转：读者在阅读一个 5 行的函数时，无法仅从代码表面得知其可能在第 2 行跳出到哪个未知上级调用者。
- 滥用通配捕获（Catch-All）：由于调用者往往无法精确穷举被调函数内部会抛出多少种运行时异常，最终往往退化为写出
except Exception:或catch (Throwable t)，将真正致命的内存溢出或逻辑 Bug 一并静默吞没。
# Java 受检异常的历史教训
Java 曾经试图兼收两者的优点：引入受检异常（Checked Exception），要求所有可能发生的业务失败必须在方法签名中通过 throws SomeException 显式声明，并在编译期强制调用方必须显式 try-catch 或继续声明传播。
# 为什么后续几乎所有新语言（C#, Kotlin, Go, Rust, Swift）全部放弃了受检异常？
- 与高阶函数和泛型流严重冲突：在 Java 8 引入 Stream API 和 Lambda 表达式后，若传递的函数体抛出受检异常，标准的
Function<T, R>接口由于未声明throws，会导致编译直接失败，迫使开发者写出极其恶心的嵌套 try-catch 包装。 - 引发大规模滥用：为了逃避繁重的声明链条，许多开发者选择机械地向上抛出笼统的
throws Exception，或者在 catch 块中写上空的注释// ignore，反而彻底抹杀了异常设计的初衷。