Java中不应滥用异常控制流程，如用NumberFormatException判断数字或抛异常跳出循环，应预检并用break或标志位；检查型异常需按恢复能力分层处理；自定义异常应分业务异常（继承RuntimeException）和系统异常（继承Exception），并提供完整构造函数；日志需带参数和%ex格式，禁用printStackTrace。
不该用异常控制流程
Java里最典型的滥用，是把 Exception 当作 if 用——比如用 NumberFormatException 来判断字符串是否为数字，或靠抛异常跳出多层循环。这会让JVM做大量无谓的栈帧填充和异常对象创建，性能损耗明显（实测比普通分支慢10–100倍），而且掩盖了真实错误意图。
正确做法是预检：用 String.matches("\\d+") 或 Integer.parseInt() 前先调 StringUtils.isNumeric()（Apache Commons）；循环退出优先用 break 标签或布尔标志位。
检查型异常（Checked Exception）该不该捕获
不是所有 Exception 子类都该被 try-catch。像 IOException、SQLException 这类检查型异常，本质是调用方必须面对的外部不确定性（文件可能被删、数据库可能断连），强行吞掉或转成 RuntimeException 会丢失上下文，让问题难以定位。
建议按三类处理：
立即学习“Java免费学习笔记（深入）”；
- 能当场恢复的（如重试一次网络请求），就捕获并处理
- 无法恢复但业务可降级的（如缓存失效时读DB），包装成业务异常（如
CacheUnavailableException）向上抛 - 完全不可控且无意义的（如
InterruptedException被中断），保留原异常并清空中断状态（Thread.currentThread().interrupt()）
自定义异常别只继承 Exception
直接 extends Exception 会导致所有使用者都被迫写 try-catch，哪怕他们根本无法处理。更合理的分层是：
- 业务异常（如
InsufficientBalanceException）→ 继承RuntimeException，调用方按需捕获 - 系统级异常（如
DatabaseConnectionException）→ 继承Exception，强制调用方声明处理逻辑 - 所有自定义异常必须提供带
String message和Throwable cause的构造函数，确保链式异常不丢根因
避免空异常：throw new BusinessException(); 没有消息和堆栈，日志里只剩一行 BusinessException，查问题时只能靠猜。
log.error() 时别只打异常类名
常见错误是 log.error("转账失败", e.getClass().getName()); 或 log.error("转账失败", e); 却没配 %ex 日志格式。结果日志里只有 java.lang.NullPointerException，看不到堆栈、参数值、甚至发生位置。
务必做到：
- 使用 SLF4J 时，用
log.error("转账失败，用户ID={}", userId, e);（注意参数顺序：消息模板、变量、异常对象） - Logback 配置中确认
%ex在 pattern 里，例如%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n%ex - 生产环境禁用
e.printStackTrace()，它不走日志框架，容易写错文件或丢失上下文
异常本身不记录业务数据，但日志消息里带关键变量（如订单号、用户ID），才能在海量日志中快速过滤归因。
