关键在于异常链完整传递：必须用带cause的构造器包装异常，避免finally抛异常，内层catch后需显式re-throw，优先使用try-with-resources自动管理资源并保留主异常与suppressed异常。
关键不是“多套几层”，而是让异常链完整传递——原始堆栈信息必须保留，不能被覆盖或截断。
用带 cause 的构造器包装异常
在 catch 块中抛出新异常时，必须把原始异常作为 cause 传入，否则堆栈就断了。
- ✅ 正确写法：throw new ServiceException("订单处理失败", e); —— 构造器接收 Throwable cause，自动保留原始堆栈
- ❌ 错误写法：throw new ServiceException("订单处理失败"); —— 新异常无关联，原始异常彻底丢失
- ⚠️ 危险写法：throw new RuntimeException("包装后异常", e); 虽保留堆栈，但类型太泛，不利于上层区分处理
避免在 finally 中抛出未捕获异常
finally 里一旦抛异常，会静默吞掉 try 或 catch 中的原始异常，连堆栈都不可见。
- 清理操作（如 close()、unlock()）若可能失败，必须自己包一层 try-catch
- 示例：try { resource.close(); } catch (IOException ignored) { logger.warn("关闭资源失败，已忽略", ignored); }
- 绝不在 finally 中写 return 或 throw —— 它会劫持整个方法的出口行为
嵌套层级要服务于错误边界，而非掩盖传播
内层 catch 不是为了“拦住”异常，而是为了做局部恢复或补充日志；若需继续上报，必须显式 re-throw。
立即学习“Java免费学习笔记（深入）”；
- 内层处理完后想交由外层统一响应？写 throw e; 或 throw new BusinessException(..., e);
- 不要写 catch (IOException e) { log.error("xxx"); } 然后沉默结束 —— 这等于丢弃异常上下文
- 外层 catch 才负责最终兜底（如转 HTTP 错误码），内层只聚焦“我能控制的那一小段”
优先用 try-with-resources 替代手动嵌套
资源打开+使用+关闭的三段逻辑，天然容易催生嵌套。而 try-with-resources 在字节码层面自动插入 finally 关闭逻辑，并且能正确合并多个异常（Suppressed Exception）。
- 当资源关闭也失败时，JVM 会把关闭异常作为 suppressed 异常附加到主异常上，e.getSuppressed() 可查
- 这样既没丢原始异常，又不增加人为嵌套，堆栈主干依然清晰可读
- 比手写 try { ... } catch { ... } finally { try { close(); } catch {} } 更安全、更简洁
