Carbon 语言错误处理原则深度解读：Errors Are Values（错误即值）-北京尧图网络

Carbon 语言错误处理原则深度解读Errors Are Values错误即值【免费下载链接】carbon-langCarbon Languages main repository: documents, design, implementation, and related tools. (NOTE: Carbon Language is experimental; see README)项目地址: https://gitcode.com/GitHub_Trending/ca/carbon-lang导读本文围绕 Carbon Language 官方设计原则文档 docs/project/principles/error_handling.md 展开系统讲解 Carbon 语言“可恢复错误必须以返回值和类型呈现”的核心设计立场。你将理解 Carbon 为什么拒绝 C/Java 式异常机制、为什么不需要noexcept/throws这类错误类型声明语法以及如何借助choice和类型系统实现高效、显式、可静态检查的错误传播。文中结合仓库内 sum types 设计文档、Core.Optional真实实现与示例代码给出可对照验证的源码级依据。一、背景可恢复失败是几乎所有程序的常态原原则文档开宗明义大多数非平凡程序中都包含“可能失败”的函数——即使调用方满足其全部前置条件函数仍可能无法完成其主要行为。文档给出两个典型例子从远程服务器读取数据的函数可能在服务器不可达时失败把字符串解析为整数的函数可能在输入字符串格式不合法时失败。这类失败与“违反前置条件”的编程错误如空指针解引用、越界访问不同关键区别在于在很多情况下函数作者希望这些失败是“可恢复的”recoverable即直接或间接的调用方能够以某种方式响应失败使程序得以继续运行。这一区分正是 Carbon 错误处理设计的出发点设计必须回答“失败信息以什么形式传递、由谁负责响应”这一根本问题。追溯历史这一原则的源头是提案 proposals/p000301-principle-errors-are-values.md。该提案明确指出“Carbon 需要一种连贯、一致的错误处理与传播方法”并提出“将 Carbon 的错误处理建立在返回值、具体地说是和类型sum types的返回值之上而不是异常或其它非返回值的旁路通道”。由于错误处理深刻影响语言的性能、安全性与可用性ergonomics这一选择对 Carbon 能否达成其设计目标至关重要。二、核心原则用和类型Sum Type返回值表达错误2.1 原则原文要点原则部分给出了 Carbon 在错误处理上的明确立场需要报告可恢复失败的 Carbon 函数应返回一个和类型sum type其备选项alternatives分别代表成功情形与失败情形例如Optional(T)、Result(T, Error)或bool。函数的成功返回值以及关于失败的元数据都应嵌入在和类型的备选项之中而不是通过输出参数或其它旁路通道来传递。Carbon 的设计将优先确保这种错误处理形式高效且符合人体工学。提炼出三个层次失败是值成功值、失败类型、失败元数据统一封装进一个和类型值拒绝旁路通道不允许用输出参数、全局状态、异常栈展开等“侧信道”携带错误设计优先级编译器必须把这种返回值式错误处理做得足够高效、写法足够轻量否则开发者会转向其它方案。2.2 和类型与choice错误值的载体“和类型”在 Carbon 中的一等公民实现是choice声明。设计文档 docs/design/sum_types.md 给出了精确定义在 Carbon 中和类型是一种其值被划分为若干命名情形称为备选项 alternatives的类型。和类型的值概念上由一个标识当前备选项的判别标签discriminator加上该备选项的值如果有组成。和类型通常通过模式匹配pattern matching来处理。以原则中提到的Optional(T)为例它本质上就是一个带Some/None两个备选项的和类型。choice语法如下来自 sum_types.mdchoice Optional(T: type) { Some(value: T), None }构造与读取var my_opt: Optional(i32) Optional(i32).None; my_opt Optional(i32).Some(42);模式匹配消费match (my_opt) { case .Some(the_value: i32) { Print(the_value); } case .None { Print(None); } }可见“错误”就是和类型中的某个备选项与成功值地位对等都由类型系统静态刻画都需要调用方用match显式分支处理。原则文档给出的Result(T, Error)同样是Ok/Err两个备选项之和而bool则是两个无参备选项的最简退化形式。三、原则的应用Carbon 错误处理的具体形态3.1 错误不会隐式传播原文档明确Carbon 的错误不像 C 等语言中的异常不会被隐式传播。这意味着调用链上的每个函数都必须主动处理或转发错误不存在“抛出后由远端 catch 捕获”的机制。这带来一个直接的设计要求既然要显式传播就必须提供一种显式但语法上轻量的错误传播手段例如 Rust 的?操作符以避免冗长的样板代码match套match让读者难以追踪成功路径的逻辑。原文档的措辞是 “very likely need to provide”即这是方向性预期具体操作符形态仍在设计中。3.2 不需要noexcept/throws式错误类型声明原文档强调两点推论无特殊语法声明“函数会发出什么错误”不需要 C 的noexcept或动态异常规范也不需要 Java 的throws因为这些信息已经内嵌在函数的返回类型里——返回类型是Optional(T)还是Result(T, Error)一眼即知函数可能失败以及失败携带什么元数据错误是静态类型的因为 Carbon 的返回值是静态类型的所以作为返回值一部分的错误自然也是静态类型的match分支可穷尽、可检查。3.3 被否决的替代方案提案中的设计决策依据提案 proposals/p000301-principle-errors-are-values.md 记录了在设计过程中被明确否决的两个替代路线理解它们有助于把握“错误即值”原则为何胜出错误与返回值解耦如 Swift 的独立 error channel需要单独的语法表示函数能否抛错且除非走 Swift 的动态类型路线否则语法还得标明错误类型还需要类似do/catch的专用语法停止错误传播、恢复普通控制流因为错误“通道”对普通代码不可见。该路线虽可能带来编译器静态区分错误/成功的性能优势但设计复杂度更高优势属于推测。同时它会让 Carbon 与“用返回码报错”的 C 代码互操作、迁移更困难。提案不推荐此路线。隐式错误传播异常路线把错误当作独立旁路通道并自动向上传播。除需要do/catch类语法外异常在代码中不可见还削弱了与 C 返回码式代码的互操作与迁移能力与 Carbon “显式优于隐式”的取向相悖。最终选择“错误即值”的简单方案并主张让后续设计由具体实践驱动、按需演进。四、仓库源码佐证原则如何落到实现原则不是空谈——仓库中的 prelude 标准库与示例代码已经在实践这一形态。4.1Core.Optional的真实实现core/prelude/types/optional.carbon 是Core.Optional的当前实现文件头注明该 API 目前是占位实现正式设计尚未定稿但其形态完全体现“和类型承载成功/失败”的思想。其核心结构class Optional(T: OptionalStorage) { fn None() - Self; fn Some(value: T) - Self; fn HasValue(self) - bool; fn Get(self) - T; ... }实现细节值得注意的两点默认存储布局源码第 110-118 行Optional(T)默认存储为一个MaybeUnformed(T)加一个bool has_value的二元组bool为false时MaybeUnformed(T)保持未初始化——这就是和类型“判别标签值”概念在内存层面的直接体现指针特化源码第 161-178 行对T*None直接复用空指针使Optional(T*)与 C 可空指针 ABI 兼容——这是原则“高效”efficient要求的具体落地避免引入额外判别位。4.2 示例用和类型承载“值或失败”示例库 examples/advent2024/io_utils.carbon 展示了真实项目中如何用和类型表达“可能失败”的读取操作。它定义class EOFType {} class CharOrEOF { adapt i32; fn EOF() - Self; }CharOrEOF实际是和类型“char或文件结束EOF”的实现ReadChar()返回CharOrEOF调用方必须用 CharOrEOF.EOF()显式判断读取是否成功而不是依赖异常。同文件还用Core.Optional(CharOrEOF)保存回退字符unread_char通过HasValue()/Get()/None()/Some()显式管理状态。这正是“失败信息嵌入返回值备选项、而非旁路通道”原则的工程化实例。4.3 静态类型错误Result 在语言设计中留下的印记原则提到Result(T, Error)时仓库设计文档也有呼应。例如 docs/design/generics/appendix-rewrite-constraints.md 在讨论接口重写约束时以Result(T, Error)这类带类型参数的和类型为讨论对象说明“成功值错误元数据”作为和类型返回值的模型已渗透到泛型与接口设计的推演中。未来Result类型同样会由choice机制定义并天然获得静态类型与模式匹配支持。五、实践要点与展望综合原则文档与仓库现状可以总结出对 Carbon 开发者的实操启示设计 API 时优先返回和类型凡可能发生可恢复失败函数签名首选Optional(T)/Result(T, Error)/bool让“失败”成为返回类型的一部分自文档化且可穷尽匹配显式传播而非隐式抛出不要期待异常式的远端捕获错误需要调用链上逐层显式处理或转发轻量传播操作符对标 Rust?是官方明确的方向错误具备静态类型借助match对choice备选项穷尽检查编译器可在编译期发现未处理的分支关注效率设计从Optional的存储布局特化默认二元组、指针复用空指针可以看出Carbon 把“返回值式错误处理的高效性”当作工程目标持续打磨。需要说明的现状边界Core.Optional在源码中被标注为占位 API、Result尚未在 prelude 中正式落地、轻量传播操作符也仍在设计中——这些都是实验阶段的真实状态与仓库 README.md 中 “Carbon Language is experimental” 的定位一致。原则已定具体机制仍在演进读者可关注 sum types 设计文档与 prelude 标准库的后续更新。参考文档索引原则原文docs/project/principles/error_handling.md立项提案proposals/p000301-principle-errors-are-values.md和类型设计docs/design/sum_types.mdCore.Optional实现core/prelude/types/optional.carbon实战示例examples/advent2024/io_utils.carbon【免费下载链接】carbon-langCarbon Languages main repository: documents, design, implementation, and related tools. (NOTE: Carbon Language is experimental; see README)项目地址: https://gitcode.com/GitHub_Trending/ca/carbon-lang创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

Carbon 语言错误处理原则深度解读：Errors Are Values（错误即值）

相关推荐

LlamaIndex NotionPageReader 完全指南：从 Notion 页面与数据库加载文档的实践与源码解析

【JAVA毕业设计】基于SpringBoot、Vue 为基础的老年健康远程数据分析与管控平台(源码+文档+远程调试，全bao定制等)

KVM切换器双屏共享方案与TESmart产品评测

更多资讯

OMX Team Worker 协议实战指南：tmux 团队协作下的 ACK、任务生命周期与邮箱协议全解析

PyTorch TorchElastic Rendezvous 完整指南：分布式任务会合机制、Backend 注册与动态集群编排

龙芯2K0300平台VL53L0X激光测距驱动移植指南

如何把 Auth0 登录接入 Refine 并重写 /login 页面完成跳转？

KMP算法详解：从暴力匹配到next数组，彻底搞懂字符串匹配

awesome-math 数学视频资源推荐：从入门到进阶的三步选片路径

今日更新

CopilotKit Vue Demo 与 React Demo 的 Parity 实现指南：路由、运行时端点与交互语义的全框架对齐

Harbor RBAC 实战：db_auth 模式下非管理员用户管理项目成员的完整验证与权限模型解析

STM32平衡车纯平衡程序从拆包到参数整定的完整调试指南

本周精选

超人会飞不算本事：系统稳定依赖清晰规则与边界设计

超人VS蜘蛛侠：拆解超级IP的影响力与传播方法论

基于CNN的调制信号识别：MATLAB实现时频图分类实战

本月热门

基于YOLO的焊缝缺陷检测：从数据标注到工业部署全流程实践

分布式服务的决策记录

创业产品的首版范围

读完文章，想聊聊您的网站？