不该用异常处理正常业务流程，如手机号校验应使用if-else而非try-catch；不该用运行时异常替代受检异常，否则剥夺调用方强制处理权；finally中不可吞掉异常，需用try-with-resources或捕获并记录；自定义异常必须保留异常链。
不该用异常处理正常业务流程
Java里把if-else逻辑硬塞进try-catch，是典型误用。比如检查用户输入手机号是否为空或格式错误，本该用StringUtils.isBlank()或正则校验，却抛出IllegalArgumentException再捕获——这会让调用方误以为发生了意外状况，也掩盖了真实控制流。
- 常见错误现象：
catch块里只做日志+返回默认值，本质是“用异常代替分支判断” - 性能影响：异常构造栈信息开销大，频繁抛出会显著拖慢吞吐（尤其在循环内）
- 可读性问题：阅读代码时，预期
catch对应的是“罕见故障”，结果发现是日常校验
不该用运行时异常替代受检异常的语义
当方法明确可能因外部依赖失败（如数据库连接中断、HTTP请求超时），却只抛RuntimeException子类，会剥夺调用方的强制处理权。Java设计Checked Exception的本意，就是让开发者直面“这个操作可能失败”的契约。
- 使用场景：DAO层的
SQLException、IO操作的IOException必须声明或捕获 - 参数差异：
throws IOException比throws RuntimeException更能表达“调用者需准备兜底逻辑” - 容易踩的坑：为图省事把
SQLException包装成RuntimeException向上抛，导致上层服务无法区分“数据不存在”和“数据库宕机”
不该在finally里吞掉异常
finally块中执行资源关闭（如close()）时，若自身抛出异常，会覆盖try块中已发生的原始异常——这是最隐蔽的异常丢失场景之一。
try {
return processData();
} finally {
resource.close(); // 若这里抛IOException，processData()里的NullPointerException就消失了
}
- 正确做法：JDK7+优先用
try-with-resources，自动抑制次要异常 - 兼容旧版本：在
finally里捕获并记录关闭异常，但不要return或throw - 关键点：原始异常的堆栈信息比资源清理失败更重要，不能被覆盖
自定义异常时不该忽略异常链
封装底层异常（如把SQLException转成业务异常UserNotFoundException）却不保留原因，等于砍掉了调试必需的上下文。
立即学习“Java免费学习笔记（深入）”；
throw new UserNotFoundException("user not found"); // ❌ 丢失SQL错误细节
throw new UserNotFoundException("user not found", e); // ✅ 保留原始异常链
- 所有自定义异常构造器都应提供
Throwable cause参数重载 - 日志框架（如SLF4J）打印
e时，会自动展开整个异常链，方便定位根因 - 容易被忽略的地方：IDE生成构造器时常漏掉
cause参数，需手动补全
catch里迷失。 
