Java异常处理指南与常见问题

本篇文章向大家介绍《Java异常使用场景及注意事项》，主要包括，具有一定的参考价值，需要的朋友可以参考一下。

不该用异常处理正常业务流程，如手机号校验应使用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）却不保留原因，等于砍掉了调试必需的上下文。

throw new UserNotFoundException("user not found"); // ❌ 丢失SQL错误细节
throw new UserNotFoundException("user not found", e); // ✅ 保留原始异常链

• 所有自定义异常构造器都应提供Throwable cause参数重载
• 日志框架（如SLF4J）打印e时，会自动展开整个异常链，方便定位根因
• 容易被忽略的地方：IDE生成构造器时常漏掉cause参数，需手动补全

异常不是控制流开关，也不是日志替代品；它只该用于真正“异常”的情况——程序无法按预期继续执行的状态。越早明确哪些场景**不该**抛异常，越能避免后期排查时在层层catch里迷失。

今天关于《Java异常处理指南与常见问题》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！