std::stoi转换失败时会抛出什么异常？

Question

当使用 `std::stoi` 函数将字符串转换为整数时，若输入字符串无法解析为有效整数（如包含非数字字符、空字符串或超出整数表示范围），该函数会抛出异常。常见的问题是：**`std::stoi` 在转换失败时具体会抛出哪些异常？它们的触发条件分别是什么？** 例如，当字符串为空或首个非空字符不是数字或符号时，会抛出 `std::invalid_argument`；而当字符串表示的数值超出 `int` 类型范围时，则抛出 `std::out_of_range`。理解这两种异常的差异对于编写健壮的输入解析代码至关重要。开发者应使用 try-catch 块正确捕获并处理这些异常，避免程序意外终止。

Answer 1

1. std::stoi 异常机制概述

在 C++ 中，std::stoi（string to integer）是 <string> 头文件中提供的一个便捷函数，用于将字符串转换为整数。尽管其使用简单，但在实际开发中，输入数据往往不可控，若未正确处理异常情况，极易导致程序崩溃。

该函数在转换失败时会抛出两种标准异常：std::invalid_argument 和 std::out_of_range。理解它们的触发条件和行为差异，是构建高可靠性系统的关键一步。

2. 两种核心异常类型详解

• std::invalid_argument：当输入字符串无法被解析为有效整数格式时抛出。
• std::out_of_range：当字符串表示的数值虽合法，但超出了 int 类型的表示范围时抛出。

这两种异常均继承自 std::logic_error 和 std::runtime_error，属于标准库定义的运行时错误类别。

3. 异常触发条件与示例分析

输入字符串	预期行为	抛出异常	原因说明
""	无效格式	std::invalid_argument	空字符串，无有效数字可解析
"abc"	无效格式	std::invalid_argument	首字符非数字或符号
" x123"	无效格式	std::invalid_argument	跳过空白后首个字符仍非法
"123abc"	部分解析失败	std::invalid_argument	C++11 起要求完全匹配，尾部非法字符也报错
"2147483648"	超出 int 上限	std::out_of_range	大于 INT_MAX (2^31-1)
"-2147483649"	低于 int 下限	std::out_of_range	小于 INT_MIN (-2^31)
" -42"	成功	无异常	允许前导空格，格式合法
"0"	成功	无异常	有效零值
"+123"	成功	无异常	允许 '+' 符号开头
"999999999999999999999"	溢出	std::out_of_range	远超 int 表示能力

4. 实际代码中的异常捕获实践

#include <iostream>
#include <string>
#include <stdexcept>

int safe_stoi(const std::string& str) {
    try {
        return std::stoi(str);
    } catch (const std::invalid_argument& e) {
        std::cerr << "解析错误：'" << str << "' 不包含有效整数。\n";
        throw; // 或返回默认值
    } catch (const std::out_of_range& e) {
        std::cerr << "范围错误：'" << str << "' 数值超出 int 范围。\n";
        throw; // 或进行截断处理
    }
}

5. 深层机制：底层实现与状态标志

虽然 std::stoi 封装了 std::strtol 的调用，但它并不提供像 pos 参数那样指示解析进度的功能。这意味着开发者无法直接知道字符串中哪一部分被成功解析。

相比之下，C 风格函数如 strtol 提供更细粒度控制：

char* end;
long val = std::strtol(str.c_str(), &end, 10);
if (*end != '\0') {
    // 存在未解析字符
}

6. 替代方案与健壮性增强策略

1. 使用 std::from_chars（C++17 起）：无异常、零开销、高性能。
2. 预验证输入：正则表达式匹配 ^[+-]?\d+$ 可提前过滤非法格式。
3. 封装通用转换模板：支持多种整型并统一异常处理逻辑。
4. 日志记录与监控：在生产环境中记录异常输入以辅助调试。
5. 结合配置中心动态调整容错级别。

7. 性能与异常成本考量

抛出异常在多数现代编译器中采用“zero-cost”模型——即正常路径无性能损耗，但一旦抛出，代价高昂。因此，在高频解析场景中应避免依赖异常作为控制流手段。

推荐在关键路径上使用无异常版本的转换函数，例如：

graph TD A[输入字符串] --> B{是否为空?} B -- 是 --> C[返回错误码] B -- 否 --> D[尝试std::from_chars] D --> E{成功?} E -- 是 --> F[返回整数] E -- 否 --> G[检查格式/范围] G --> H[返回默认值或抛出自定义异常]

8. 工程化建议与最佳实践

在大型系统中，建议将字符串转整数操作抽象为服务层函数，集中管理以下方面：

• 国际化数字格式支持（如千分位分隔符）
• 安全边界检查
• 审计日志输出
• 与配置联动的宽松/严格模式切换
• 单元测试覆盖各类边界情况