应只捕获具体异常类型，避免捕获Throwable或泛型Exception；受检异常须显式处理而非静默吞掉；finally中勿覆盖原始异常；自定义异常需依场景选择继承RuntimeException或Exception。
不要在 catch 块里捕获 Throwable 或 Exception
捕获 Throwable 会吞掉 OutOfMemoryError、StackOverflowError 等 JVM 严重错误，导致程序在不可恢复状态下继续运行；捕获泛型的 Exception 则大概率掩盖本该向上抛出的受检异常意图，或误吞 InterruptedException 这类需特殊处理的异常。
实操建议：
- 只捕获你明确知道如何处理的具体异常类型，例如
IOException、SQLException - 若需兜底，用
catch (RuntimeException e)+ 单独catch (Error e)（且通常应记录后重新抛出） - 避免写
try { ... } catch (Exception e) { log.error("unexpected", e); }—— 这不是容错，是埋雷
受检异常（checked exception）不该被“静默吞掉”
Java 要求显式处理受检异常，但很多人用空 catch 块、仅打印日志却不重试/补偿/通知，等于把业务逻辑的失败信号直接丢弃。调用方完全感知不到操作其实失败了。
常见错误现象：
立即学习“Java免费学习笔记（深入）”；
-
catch (IOException e) { /* empty */ }—— 文件写失败，但后续代码仍假设文件已落盘 -
catch (SQLException e) { logger.warn("DB failed", e); return null; }—— 上层拿到null却未做判空，触发NullPointerException
正确做法：
- 要么恢复：重试、降级、返回默认值（需明确语义，如缓存读取失败时返回旧值）
- 要么转换：包装成更上层能理解的业务异常，如
throw new OrderCreationFailedException("payment timeout", e); - 要么声明抛出：如果当前方法无法处理，就加
throws IOException，让调用方决策
别在 finally 里覆盖原始异常
当 try 块抛出异常，而 finally 块又抛出另一个异常时，原始异常会被彻底丢失 —— JVM 只保留 finally 中抛出的那个，调试时根本看不到真正出问题的地方。
示例问题代码：
try {
return readFile(path);
} finally {
closeStream(); // 若这里抛出 IOException，readFile 的异常就消失了
}解决方式：
- 用 try-with-resources 替代手动
close()，它会自动抑制次要异常 - 若必须手动关闭，应在
finally中用if (resource != null) resource.close();并捕获其异常，不抛出 - JDK 7+ 可用
Throwable.addSuppressed()显式保留原始异常，但日常开发中优先选前两种
自定义异常别滥用 extends Exception
继承 Exception 意味着强制调用方处理，但如果这个异常本质上是程序 bug（比如传入非法参数），应该继承 RuntimeException；反之，如果异常代表外部可恢复故障（如网络超时），才考虑设计为受检异常。
判断依据：
- 调用方能否预见该异常发生？能 → 受检；不能（纯逻辑错）→ 非受检
- 调用方是否有合理手段恢复？有（如重试、切换备用源）→ 受检；无 → 非受检
- 是否需要强制 API 使用者关注失败路径？是 → 受检；否则非受检更轻量
一个容易被忽略的细节：自定义异常构造函数务必调用 super(message, cause)，否则链路追踪时会丢失根因堆栈。
