std::uncaught_exceptions为何返回int类型而非size_t？

由于std::uncaught_exceptions返回的是已抛出异常的计数，直觉上数值为负完全不符合逻辑，且size_t的位宽通常大于int，看起来溢出风险更低。对应的两个技术疑问可以明确解答如下：

1. std::uncaught_exceptions是否可能返回负值？触发条件是什么？ #

符合C++标准要求的正确实现中，该接口不可能返回负值。
从接口语义看，它的返回值是当前线程内「已抛出但尚未被catch块捕获处理的异常数量」：初始值为0，每抛出一个新异常、启动栈展开流程时计数加1，每完成一个异常的catch匹配、进入异常处理逻辑时计数减1，整个计数生命周期里没有减到0以下的合法路径。
只有当编译器/标准库存在实现bug时，才可能出现负值返回值——比如早期个别编译器对嵌套异常的栈展开计数维护逻辑有疏漏，在异常重抛出、嵌套析构抛异常的场景下计数错误递减，这类属于厂商实现缺陷，不是接口设计允许的合法返回值，遇到直接向对应编译器厂商提交bug即可。

2. 为什么该接口返回值没有选择位宽更大的整数类型？ #

这个选择是多重因素权衡的结果，和溢出风险几乎无关：

• 首先是历史兼容原因：C17正式标准化带s后缀的多异常计数版本std::uncaught_exceptions之前，工业界已经有十余年的第三方实现原型，这些原型普遍沿用了C98时代单异常版本std::uncaught_exception的整数返回类型设计，标准化时为了兼容已有存量代码，没有改动返回类型。
• 其次不存在实际溢出可能：标准要求int的最小位宽是16位，对应最大正数值是32767。现实程序中根本不可能出现嵌套3万多层未捕获异常的场景——真到这个嵌套深度，程序栈早就因为栈溢出直接崩溃了，根本轮不到计数溢出的问题发生。
• 无符号类型反而会引入更多易错点：如果选用size_t这类无符号类型做返回值，一方面如果出现实现bug导致计数小于0，会直接回绕为一个极大的正整数，比负值更难排查；另一方面无符号类型的隐式转换、减法回绕特性很容易让使用者写出逻辑错误的代码，比如判断当前异常嵌套深度是否大于2时，无符号返回值会让uncaught_exceptions() - 2 > 0在计数小于2时也返回true，这类隐蔽bug的排查成本极高，用有符号int反而能规避这类问题。

内容的提问来源于stack exchange，提问作者siga