应避免在循环中抛异常，因其创建开销大、易引发GC；禁用无意义的try-catch和空catch；优先用unchecked exception并定义语义化子类；高频场景可禁用堆栈以提升性能，但需权衡调试与监控需求。
不要在循环里用 throw new Exception() 制造异常
异常对象创建开销大，尤其是堆栈跟踪（StackTraceElement[]）的生成和填充。在高频循环中抛出异常，会显著拖慢性能，还可能触发 GC 压力。
常见错误场景：用异常控制流程，比如遍历集合时靠捕获 NoSuchElementException 来判断结束；或校验参数时对每个非法值都抛 IllegalArgumentException。
- 改用布尔返回值或 Optional 判断前置条件，例如
if (!list.isEmpty()) { ... }而非依赖iterator.next()抛异常 - 批量校验应聚合错误信息，一次性抛出（如自定义
ValidationException包含List<string></string>错误描述），而非逐个抛 - 若必须抛异常，确保它不发生在热点路径（如每毫秒调用数百次的方法内）
优先使用 unchecked exception，但别滥用 RuntimeException
Java 的 checked exception 强制调用方处理，看似安全，实则常被 catch (Exception e) { e.printStackTrace(); } 消灭，反而掩盖问题。而无意义的 try-catch 套路会增加代码噪音和维护成本。
关键判断标准：该异常是否属于「调用方有能力且应该恢复」的场景？
立即学习“Java免费学习笔记（深入）”；
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
- IO、网络超时、数据库连接失败等——适合 checked（如
IOException,SQLException），因为调用方可能重试或降级 - 空指针、数组越界、类型转换失败等——本质是 bug，应修复代码，而非捕获；用 unchecked 更合理
- 避免直接 throw
RuntimeException，而是定义语义明确的子类，如InvalidOrderStateException，便于监控和分类统计
catch 块里别空着，也别只打日志就完事
空 catch 是最危险的静默失败；只调 e.printStackTrace() 或 log.error("", e) 而不记录上下文，会让线上问题难以定位。
实际处理要分情况：
- 可恢复场景（如缓存加载失败）：记录带 traceId 和关键参数的日志，再 fallback 到备用逻辑
- 不可恢复但需通知场景（如支付回调验签失败）：记录完整请求体 + 异常堆栈，并触发告警（如发消息到运维群）
- 绝对不能吞掉异常后继续执行后续业务逻辑，除非你明确知道那部分与当前异常完全无关且幂等
自定义异常别忘了重写 fillInStackTrace() 以提升性能
默认的 Throwable.fillInStackTrace() 会采集当前线程全部栈帧，耗时可观。对高频、低业务价值的异常（如内部状态校验失败），可考虑禁用。
适用前提：该异常仅用于控制流或快速失败，不需要完整堆栈用于诊断。
- 继承
RuntimeException后重写：public class FastFailException extends RuntimeException { public FastFailException(String message) { super(message, null, false, false); // disable stacktrace & cause } } - 注意：禁用后
e.getStackTrace()返回空数组，IDE 调试和 APM 工具将无法展示调用链，慎用于对外接口或核心链路 - 更适合用在框架层内部、或模块间契约明确的边界检查（如 RPC 序列化前字段校验）
exception_count{type="InvalidParamException"} 标签，导致出了问题只能翻日志，没法看趋势、做同比、设阈值告警。 
