信息发布→ 登录 注册 退出

c++23的std::expected如何优雅地处理函数错误? (替代异常和错误码)

发布时间:2026-01-09

点击量:
std::expected 是 C++23 引入的值语义错误处理工具,本质是 std::variant 的封装,适合替代错误码而非异常,用于需显式传播错误但禁用异常的场景(如嵌入式、系统调用),不适用于需栈展开或不可恢复错误。

std::expected 是什么,它适合替代异常还是错误码?

std::expected 是 C++23 引入的值语义错误处理工具,本质是 std::variant 的封装,其中 T 是成功值类型,E 是错误类型(通常为 std::error_code 或自定义错误枚举)。它既不抛异常,也不靠返回码隐式判断,而是把「结果」和「错误」都显式打包进一个对象里。

它适合替代「需要明确传播错误但又不想用异常」的场景,比如嵌入式、游戏引擎底层、系统调用封装、异步 I/O 回调链。不适合替代异常的场景:需要栈展开清理资源、错误不可恢复且应立即中止流程。

常见误用是把它当 bool 用——只检查 has_value() 就丢掉 error(),这等于把错误码又变回了“忽略型错误码”。

如何从函数返回 std::expected 并保持调用链清晰?

关键不是“怎么返回”,而是“怎么让调用方不用写一堆 if (!res.has_value())”。推荐组合使用 and_then(C++23)和手动解包逻辑。

  • and_then 接收一个 std::expected (T&&) 形式的函数,自动在 has_value() == true 时调用,并透传错误;失败时直接短路返回原错误
  • 避免裸写 res.value() —— 它会 throw std::bad_expected_access,除非你确定已检查过
  • 对可预期的错误(如文件不存在),优先用 error() 获取后做分支;对意外错误(如 std::errc::io_error),可转为 std::unreachable() 或日志后 abort
std::expected parse_int(std::string_view s) {
    char* end;
    long v = std::strtol(s.data(), &end, 10);
    if (*end != '\0') return std::unexpected{std::errc::invalid_argument};
    if (v < INT_MIN || v > INT_MAX) return std::unexpected{std::errc::result_out_of_range};
    return static_cast(v);
}

auto res = parse_int("42") .and_then([](int i) -> std::expected { if (i < 0) return std::unexpected{std::errc::invalid_argument}; return i * 2; }); // res 是 std::expected,无需手动判空

std::expected 和 std::error_code 配合时要注意哪些陷阱?

std::expected 是最常用组合,但容易踩三个坑:

  • 不要直接用 std::make_error_code 构造泛型错误——它不保证跨编译单元唯一性;应统一用 std::errc 或自定义 std::error_category
  • std::error_code 默认可隐式构造,导致 std::expected{42} 编译通过,但其实是把 42 当作 error 构造了!务必显式用 std::expected{std::in_place, 42} 或直接写 std::expected{42} 仅当 T 可隐式转换自 int(不推荐)
  • 比较两个 std::error_code 要用 ==,不是 .value() == —— 后者忽略 category,可能误判(例如 std::errc::no_such_file_or_directory 和 Windows 的 ERROR_FILE_NOT_FOUND 值相同但 category 不同)

什么时候不该用 std::expected?

它不是银弹。以下情况建议退回更轻量或更重的方案:

  • 函数只可能失败一次且调用方必定要处理(如打开配置文件),用 std::optional + 独立错误日志更简单
  • 错误类型太多、需要动态派发(如网络协议多层错误码映射),std::variantstd::expected 更灵活,但失去值语义一致性
  • 已有成熟异常体系(如大型服务端框架),强行改用 std::expected 会割裂错误处理风格,增加心智负担
  • 性能敏感路径(如 inner loop 中频繁创建 std::expected),注意其移动构造/赋值仍有开销,比纯 int 返回码重

最常被忽略的一点:std::expected 的真正价值不在单个函数,而在整条调用链的错误透明传递。如果只有出口函数检查错误,中间全用 .value() 强解,那和裸指针解引用没区别——崩溃只是早晚问题。

标签:# go  # 隐式  #   # 值类型  # 泛型  # 对象  # 异步  # 错误码  # 自定义  # 指针  # 太多  # 什么时候  # 已有  # 而在  # 把它  # 要用  # 不存在  # int  # bool  # Error  # throw  # 封装  # if  # 隐式转换  # 区别  # 配置文件  # win  # c++  #   # 工具  # access  # windows  
在线客服
服务热线

服务热线

4008888355

微信咨询
二维码
返回顶部
×二维码

截屏,微信识别二维码

打开微信

微信号已复制,请打开微信添加咨询详情!