C++如何使用std::expected处理错误返回（C++23）-C++-PHP中文网

c++oding="utf-8" ?>

std::expected适用于有明确成功值和确定错误类型的i/o或数据转换场景，且调用方不希望异常中断或使用魔法值；不适合底层系统调用、泛型错误路径或运行时不确定错误类型的情况。

c++如何使用std::expected处理错误返回（c++23）

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

它不是 std::optional 的替代品，也不是 throw 的平替。真正适合的场景是：函数明确有「成功值」和「确定错误类型」两个互斥结果，且调用方**不希望异常中断控制流**，也不愿用魔法返回值（比如 -1、nullptr）或输出参数。

常见误用：包装可能抛异常的函数（比如 std::stoi）却不处理 std::invalid_argument——这会让错误被静默吞掉；或者用 std::expected<void e></void> 当作“无返回值 + 错误”时，却忘了 void 类型无法被拷贝，必须用 std::move 传递。

适合：文件打开、JSON 解析、网络请求响应解析等边界清晰、错误可枚举的 I/O 或数据转换操作
不适合：底层系统调用封装（errno 变化多端）、模板元编程中泛型错误路径、或错误类型本身不确定（如需要运行时字符串描述）
注意：std::expected 对象本身不可默认构造，声明时必须初始化为 std::expected<t e>{value}</t> 或 std::expected<t e>{std::unexpect, error}</t>

如何正确构造和检查 std::expected

别用 .has_value() + .value() 组合——一旦 .value() 在无值时调用，行为未定义（不是抛异常，是 UB）。正确方式是先用 .has_value() 判断，再用 .value() 或 .error()；或者直接用 if (auto r = func(); r) { /* success */ } else { /* r.error() */ }。

示例：

C++ Code Review Master

组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。

下载

std::expected<int std::string> parse_int(const std::string& s) {
    try {
        return std::stoi(s);
    } catch (const std::exception&) {
        return std::unexpected("invalid integer format");
    }
}
<p>auto r = parse_int("42");
if (r) {
std::cout </p>
<ul>
<li>
<code>*r</code> 和 <code>r.value()</code> 等价，但仅在 <code>r.has_value()</code> 为 true 时合法</li>
<li>
<code>r.error()</code> 同理，只在 <code>!r.has_value()</code> 时可用</li>
<li>不要对临时 <code>std::expected</code> 对象取地址或绑定到非 const 引用——移动语义可能让后续访问失效</li>
</ul>
<h3>链式调用与错误传播怎么写才不崩</h3>
<p><code>std::expected</code> 没有内置 <code>map</code> 或 <code>and_then</code>（C++23 标准没提供），得自己写或借助第三方（如 <code>tl::expected</code>）。标准库只给了 <code>.transform()</code>（C++23 起），但它要求传入的 callable 返回 <code>T</code> 或 <code>std::expected<u e></u></code>，且失败时自动短路。</p>
<p>关键限制：<code>.transform()</code> 不接受返回 <code>std::expected<u f></u></code>（F ≠ E）的函数——错误类型必须一致，否则编译失败。想做错误类型转换，得手动解包再重建。</p>
<ul>
<li>安全链式写法示例：</li>
<li><code>auto r = parse_int("123").transform([](int x) { return x * 2; }); // r 是 std::expected<int std::string></int></code></li>
<li>错误转换需显式处理：<code>if (!r) return std::unexpected(std::make_error_code(std::errc::invalid_argument));</code>
</li>
<li>嵌套调用时，避免连续多个 <code>.transform()</code> 套娃——每层都增加一层临时对象开销，且可读性骤降</li>
</ul>
<h3>和传统错误处理方式对比时的真实代价</h3>
<p>比起 <code>errno</code> 或返回码，<code>std::expected</code> 占用更大内存（通常至少两个指针宽度），且不能零成本抽象：即使你从不使用错误分支，编译器也得为 <code>std::unexpected</code> 分支生成代码。但在 debug 构建下，它比异常更可控；在 release 下，若编译器能证明错误路径永不执行，优化后可能接近内联返回码。</p>
<p>真正容易被忽略的是 ABI 兼容性：<code>std::expected<t e></t></code> 的二进制布局未标准化，不同标准库实现（libstdc++ / libc++ / MSVC STL）之间不能直接传递。跨动态库边界时，要么统一 STL 实现，要么只传 POD 类型并自行序列化错误。</p>
<ul>
<li>小对象（如 <code>std::expected<int std::errc></int></code>）通常能放进寄存器，性能影响微乎其微</li>
<li>大错误类型（如 <code>std::string</code>）会触发堆分配，且移动构造可能比简单整数返回慢一个数量级</li>
<li>如果项目已重度依赖 <code>boost::system::error_code</code>，强行切到 <code>std::expected<t std::error_code></t></code> 并不会自动获得兼容性——错误码语义仍需手动映射</li>
</ul></int>

C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！