catch(exception e)会吞掉nullpointerexception等运行时异常，导致排查困难、状态错乱；应按场景捕获具体异常，如ioexception、sqlexception，并在顶层兜底时记录完整堆栈。
catch(Exception e) 会吞掉哪些关键异常
直接 catch(Exception e) 会捕获除 Error 及其子类（如 OutOfMemoryError、StackOverflowError）外的所有异常，包括本该让程序崩溃的严重问题。比如 NullPointerException、ArrayIndexOutOfBoundsException 这类运行时异常，它们通常反映代码逻辑缺陷，不该被静默吞掉。
常见错误现象：
— 日志里只打印了 “Exception caught”，没带堆栈，排查困难
— 程序看似正常运行，但后续状态错乱（比如对象为 null 却继续执行）
— 单元测试通过，生产环境偶发数据不一致
- 除非明确知道要兜底处理（如顶层守护线程），否则不要用
catch(Exception e) - 若真需兜底，至少加上
e.printStackTrace()或完整日志记录，不能只System.out.println(e) - 避免在业务方法里用它替代具体异常处理，这会让调用方失去错误语义
应该 catch 哪些异常：检查型 vs 非检查型
Java 异常分两类：Exception 的子类中，继承自 RuntimeException 的是非检查型异常（编译器不强制处理），其余是检查型异常（编译器强制你 try/catch 或 throws）。
使用场景决定捕获粒度：
— 文件读写：应捕获 IOException，而不是笼统的 Exception
— 数据库操作：优先捕获 SQLException，必要时再区分 SQLTimeoutException 或 SQLNonTransientException
— HTTP 调用：用 IOException 处理连接失败，用 InterruptedException 响应中断信号
立即学习“Java免费学习笔记（深入）”；
- 对检查型异常，按实际可能抛出的具体类型捕获，比如用
catch(NoSuchFileException e)替代catch(IOException e)（如果确定只会缺文件） - 非检查型异常一般不主动 catch，除非你在做防御性日志、清理资源或转换为业务异常（如把
NumberFormatException转成InvalidParameterException） - 多个具体异常可共用一个 catch 块（Java 7+）：
catch(IOException | SQLException e)
try-catch 放在哪一层最合适
异常处理位置比“捕获什么”更影响可维护性。不是所有地方都适合 try/catch —— 它该出现在能做出有意义响应的地方。
典型误用：
— DAO 层 catch SQLException 后吞掉或打印日志，却不 re-throw 或转成业务异常
— Service 层对每个远程调用都套独立 try/catch，导致重复日志和状态混乱
— Controller 层只 catch Exception，统一返回 500，掩盖了客户端可修复的错误（如参数格式错）
- 底层（如工具类、SDK 封装）应往外抛异常，或转为更明确的自定义异常（如
NetworkUnavailableException） - 中间层（Service）负责聚合异常语义，比如把多种 IO 异常统一为
DataLoadFailedException - 顶层（Controller / main 方法）才做最终兜底，此时可 catch
Exception，但必须区分是否要返回用户友好提示、是否要告警、是否要记录全量堆栈
log.error(e) 和 log.error("msg", e) 的区别很关键
很多团队习惯写 log.error(e.toString()) 或 log.error("failed", e)，但后者才能保留堆栈。前者只打出了异常类名和 message，丢掉了最关键的 trace。
性能与兼容性影响：
— log.error("load user failed", e) 是标准做法，SLF4J / Log4j 都支持
— 不要用 e.printStackTrace() 输出到控制台，它不走日志框架，无法配置级别、输出目标或异步化
— 在高并发场景下，频繁打印完整堆栈可能拖慢响应，可考虑采样（如每千次打一次全量）或仅在 debug 级别输出
- 永远用
log.error(String, Throwable)形式，而不是拼字符串 +e.getMessage() - 在 catch 块里，不要只记录日志就完了；考虑是否需要清理资源（如关闭流）、重试、降级或通知监控系统
- 如果异常已包装过（如
new ServiceException("xxx", e)），不要再用原异常二次 log，避免堆栈重复
catch(Exception e) 往往意味着开发者放弃了对错误原因的表达权。 
