C++整数除零是未定义行为，直接触发SIGFPE等信号而非异常，无法用try/catch捕获；安全做法是除前检查y==0及INT_MIN/-1溢出；浮点除零默认生成inf/nan，需手动启用浮点异常或显式校验。
除零在C++里根本不会抛出异常
标准C++运行时对整数除零不定义行为，std::div、/、% 这些操作遇到除数为0时，程序直接崩溃（Linux/macOS 是 SIGFPE，Windows 是 EXCEPTION_INT_DIVIDE_BY_ZERO），不是std::exception子类，try/catch(...) 捕不到。
浮点数除零倒是有定义：按IEEE 754，1.0 / 0.0 得 inf，0.0 / 0.0 得 nan，但默认不触发异常——除非你手动开启浮点异常（如用 feenableexcept(FE_DIVBYZERO)）。
- 别写
try { x / y; } catch(...) { ... }期待捕获整数除零——它永远进不去catch - 调试时看到
Signal: SIGFPE (Arithmetic exception)就是这里崩了 - 编译器（如GCC/Clang）加
-fsanitize=undefined可在运行时报出division by zero并附调用栈，比静默崩溃友好得多
怎么安全地检查除零（整数场景）
最可靠的方式永远是「除前判断」，而不是依赖事后捕获。尤其在嵌入式、高频计算或系统级代码中，信号处理开销大、不可控，且跨平台行为不一致。
常见错误是只判 y == 0，但漏掉有符号整数的边界情况：INT_MIN / -1 在补码下会溢出（仍是未定义行为），虽不是除零，但同样崩溃。
立即学习“C++免费学习笔记（深入）”；
- 对
int类型，检查条件应为：if (y == 0 || (y == -1 && x == INT_MIN)) - 用
std::div前也得自己检查除数，它不校验 - 若逻辑上除数本不该为零（如配置项、用户输入），建议用
assert(y != 0)+ 单元测试覆盖该分支，比运行时兜底更早暴露问题
想用信号处理兜底？小心跨平台和线程
Linux用 signal(SIGFPE, handler) 或 sigaction 可捕获除零信号，但Windows要用 SetUnhandledExceptionFilter 或结构化异常（SEH），两者API、语义、线程安全性完全不同。
更大的问题是：信号处理函数内能做的事极少（异步信号安全函数列表极短），不能调用 std::cout、malloc、printf，甚至不能安全地 longjmp 回原上下文——多数时候只能记录日志后 _exit。
- 多线程下，
signal()行为未定义；必须用pthread_sigmask+sigwait配合sigaction才可控 - 即使捕获成功，程序状态已损坏（寄存器/栈可能不一致），继续执行风险极高
- 仅建议用于顶层错误上报（如写 crash dump），绝不用于“恢复运算”
浮点除零要不要管？看场景
默认情况下，float/double 除零生成 inf 或 nan，不中断执行。这在科学计算、图形渲染中常是合理行为（比如归一化向量时长度为0 → 结果全nan，后续用 isnan() 过滤即可）。
但金融、控制逻辑等要求强确定性的场景，必须提前拦截。此时不应依赖信号，而应开启浮点异常并用 feholdexcept/feraiseexcept 精确控制。
- 启用除零异常：
feenableexcept(FE_DIVBYZERO)（需<cfenv></cfenv>） - 之后
1.0f / 0.0f会触发SIGFPE，同整数——仍不能用try/catch捕获 - 更稳妥的做法是：用
std::isfinite(x) && std::isfinite(y) && y != 0.0显式过滤，兼容性最好
真正难的不是“怎么拦”，而是想清楚：这个除零是逻辑缺陷（该提前校验），还是数据自然边界（该接受 inf 并下游处理）。后者往往被忽略，结果 nan 一路传染到最终结果才暴露。
