应只捕获具体异常类型而非exception或throwable，确保异常语义清晰、处理动作明确、错误不被静默丢弃；中间层禁止泛捕，兜底逻辑统一收口至web层或网关层，并通过工具强制约束宽泛捕获。
别用 catch (Exception e) 当万能兜底，它看起来省事，实则埋雷——既可能吞掉空指针这类代码 bug，又会掩盖本该由上层决策的受检异常（比如 IOException），让问题延迟暴露、定位困难。
只捕获你真能处理的异常类型
异常不是用来“拦住”的，而是用来“识别并响应”的。每种具体异常都携带明确语义：
- FileNotFoundException：说明文件路径不对或权限不足，可触发创建默认配置、提示用户检查路径；
- SQLException：代表数据库交互失败，适合做重试、降级或转成业务异常（如 DataAccessException）；
- NumberFormatException：输入解析出错，应返回友好提示而非让整个流程静默失败。
泛泛捕获 Exception，等于放弃这些关键信息，所有错误都走同一套逻辑，结果就是“什么错了不知道，怎么修更不知道”。
按从具体到宽泛顺序排列多个 catch 块
Java 按照 catch 块声明顺序匹配异常类型。如果把 catch (Exception e) 放在前面，后面再写 catch (IOException e) 就永远执行不到。
正确写法示例：
try {
readFile();
} catch (FileNotFoundException e) {
log.warn("配置文件缺失，使用默认值", e);
loadDefaults();
} catch (IOException e) {
log.error("读取配置失败，将触发告警", e);
triggerAlert();
}
这样既能精准响应，又能防止遗漏。
外层兜底要有明确目的，不能代替分层处理
全局异常处理器（如 Spring 的 @ExceptionHandler、Servlet 的顶层 try-catch）可以捕获 Exception，但前提是：
- 必须记录完整堆栈（不能只打 message）；
- 要区分是系统错误（如 OOM）还是业务异常，对前者应快速终止、避免污染状态；
- 不能在 service 或工具方法里这么干——它们该把异常暴露出去，由更有上下文的调用方决定怎么处理。
不确定时宁可不捕，也不要静默吞掉
遇到一个你暂时没想好怎么处理的异常，比写个空 catch 块或只打一行日志更稳妥的做法是：
- 先
catch (Throwable t)打全量日志（含线程名、堆栈、上下文参数）； - 然后立即
throw new RuntimeException("原始操作失败", t)包装重抛； - 确保异常不被吃掉，同时为后续排查留足线索。
真正的健壮，不来自“全拦住”，而来自“看得清、分得明、动得准”。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
