不能用ArithmeticException做动态采样控制，因其是表示未预期算术错误的异常信号，违背异常设计原则，会导致可读性差、性能开销大、行为不可靠且掩盖真实缺陷；应改用显式条件判断、策略模式或监控指标驱动采样逻辑。
不能也不应该用 ArithmeticException 主动触发或驱动业务逻辑（如采样范围调整）。它是一个**错误信号**，代表程序出现了未预期的算术异常（如除零、整数溢出），而非设计用来做流程控制的机制。
为什么不能用 ArithmeticException 做动态采样控制
违背异常设计原则：Java 异常机制的核心目的是处理“意外情况”，不是替代 if/else 或状态机。用异常做流程分支会导致代码可读性差、性能开销大（异常创建和栈展开代价高）、难以调试和测试。
不可靠且危险：依赖抛出 ArithmeticException 来改变采样逻辑，意味着你必须主动制造非法运算（如 int x = 1 / 0;），这会让代码充满副作用、破坏数据一致性，且在 JIT 优化或不同 JVM 版本下行为可能不稳定。
掩盖真实问题：把业务决策逻辑伪装成“异常处理”，会让真正的数值越界、配置错误等缺陷被忽略，后期维护成本极高。
推荐的替代方案：显式条件判断 + 策略配置
动态调整采样范围应基于明确的输入参数、阈值规则或运行时指标，而非异常。例如：
- 根据当前数据量大小选择采样率：
if (totalCount > 1_000_000) { samplingRate = 0.01; } - 依据系统负载（CPU/内存）动态降级采样：
if (systemLoad > 0.8) { samplingRate *= 0.5; } - 使用策略模式封装不同采样逻辑：
SamplingStrategy strategy = getStrategyByEnv(); strategy.sample(data);
如果非要“响应异常”来调整——正确做法是事后兜底
仅在极少数场景下，你可能想对**真实发生的数值异常**做出响应（比如上游传入非法参数导致计算崩溃），此时应：
- 捕获
ArithmeticException，记录告警并 fallback 到安全默认值（如固定采样率 0.001） - 触发配置热更新或人工干预流程（如推送消息到运维群）
- 绝不在此处修改核心采样算法逻辑，而是视为故障信号启动容错机制
小结
用 ArithmeticException 实现动态采样是反模式。请用清晰的状态判断、外部配置或监控指标驱动采样策略。异常只该用于处理意外，不该成为流程开关。
