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，哪怕他们根本无法处理。更合理的分层是：
