捕获 Exception 本身不是坏习惯，但不加区分地捕获会掩盖编程错误、干扰异常语义、误吞关键异常并导致日志失真；应优先捕获具体异常，仅在顶层兜底或特殊场景下谨慎使用。
捕获 Exception 本身不是“坏习惯”，但**在不加区分、不加约束地捕获它时，确实会带来显著风险**。关键不在于能不能捕，而在于是否理解它覆盖了什么、是否真的需要处理所有这些异常。
它到底捕获了什么？
Exception 是除 Error 外所有异常的父类，包括：
-
受检异常（Checked）：如
IOException、SQLException，编译器强制你处理； -
非受检异常（Unchecked）：如
NullPointerException、IllegalArgumentException、ArrayIndexOutOfBoundsException，通常反映编程错误或不可恢复状态； - 自定义业务异常：可能本应向上抛出或由特定逻辑处理。
用一个 catch (Exception e) 把它们全兜住，等于模糊了“可恢复故障”和“程序缺陷”的边界。
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
典型风险场景
-
掩盖空指针等编程错误：本该修复的
NullPointerException被静默吞掉，导致后续逻辑错乱或数据损坏； -
干扰异常传播语义：比如 DAO 层抛出
SQLException，Service 层却用Exception捕获后转成通用错误码，丢失了数据库连接失败、SQL语法错误等关键上下文； -
误吞本该终止流程的异常：如
InterruptedException被捕获却不恢复中断状态，导致线程无法被优雅关闭； -
日志失真、排查困难：只记录
e.toString()，不打印堆栈，或统一打成“系统异常”，运维根本看不出是配置缺失还是网络超时。
更合理的做法
-
按契约捕获具体异常：调用
Files.readAllLines()就明确 catchIOException；调用 JDBC 就分别处理SQLException和可能的SQLTimeoutException； -
用多重 catch 或异常过滤（Java 7+）：
try { // ... } catch (IOException e) { log.warn("文件读取失败", e); throw new BusinessException("文件不可用", e); } catch (IllegalArgumentException e) { throw new BusinessException("参数非法", e); // 快速失败 } -
顶层兜底需谨慎：在 Web 全局异常处理器（如 Spring 的
@ControllerAdvice）中捕获Exception是常见且合理的，但必须区分日志级别、返回状态码，并排除已知不应捕获的类型（如OutOfMemoryError子类）； -
绝不静默吞异常：哪怕只是
log.error("意外异常", e)，也要保留完整堆栈；避免catch (Exception e) { }这类空处理。
什么时候可以接受 catch(Exception)？
极少数场景下它是务实选择：
立即学习“Java免费学习笔记（深入）”；
- 作为最外层守护线程的“最后防线”，确保线程不死，同时记录并上报严重异常；
- 集成第三方 SDK，其文档未明确声明抛出哪些异常，且 SDK 自身无合理错误分类时，先兜住再逐步细化；
- 脚本式工具类（非生产核心逻辑），追求快速交付且异常影响可控。
即便如此，也建议加上注释说明原因，并配套监控告警，而不是当作默认模式。
