不会。直接 throw e; 保留原始堆栈；throw new RuntimeException(e) 会改变顶层异常类型和堆栈；finally 中 throw 会覆盖 catch 异常；getCause() 表示因果关系，getSuppressed() 表示 try-with-resources 中被压制的次要异常。
直接 throw 原异常对象会丢失堆栈吗？
不会。用 throw e;（其中 e 是捕获到的异常引用）重新抛出，原始堆栈跟踪完整保留，调用链上所有方法帧都还在 printStackTrace() 中可见。
常见错误是误写成 throw new RuntimeException(e); 或 throw new RuntimeException(e.getMessage()); —— 这会切断原始异常链，丢失根因位置。
- ✅ 正确：
catch (IOException e) { throw e; } - ❌ 错误：
catch (IOException e) { throw new RuntimeException(e); }（虽保留 cause，但顶层异常类型和堆栈已变） - ⚠️ 注意：若需包装但又不破坏上下文，应显式传入
cause并保留原类型意图，例如throw new MyServiceException("读取配置失败", e);
使用 throws 声明后，调用方必须处理吗？
仅对 checked 异常强制要求。Java 区分 checked（编译期检查）和 unchecked（RuntimeException 及其子类）异常。
throws IOException 出现在方法签名中，调用方要么 try-catch，要么继续向上声明；而 throws IllegalArgumentException 不触发编译错误，可忽略。
立即学习“Java免费学习笔记（深入）”；
- checked 异常代表“预期外但可恢复的外部问题”，如文件不存在、网络超时
- unchecked 异常代表“编程错误或不可恢复状态”，如空指针、数组越界
- 过度使用
throws会导致调用方被迫处理本该由上游兜底的逻辑，反而模糊责任边界
在 finally 块里 throw 会覆盖 catch 中的异常吗？
会，且静默吞掉原始异常。这是最易被忽略的陷阱之一。
当 catch 块已抛出异常，随后 finally 块也执行了 throw，JVM 会丢弃 catch 抛出的那个，只传播 finally 中的新异常。
- ❌ 危险写法：
try { riskyOperation(); } catch (SQLException e) { throw new ServiceException("DB error", e); } finally { if (conn != null) conn.close(); // 若 close() 抛出 SQLException，它会取代上面的 ServiceException } - ✅ 安全做法：避免在
finally中抛异常；若资源关闭可能失败，应单独捕获并记录，不向上抛 - ? Java 7+ 推荐用 try-with-resources 替代手动
finally关闭，自动抑制次要异常（通过addSuppressed()）
异常链（getCause()）和 suppressed 异常的区别？
getCause() 表示“这个异常是由另一个异常引发的”，用于构造时显式传递；getSuppressed() 是 try-with-resources 自动添加的“被压制的异常”，发生在主异常抛出过程中，其他资源关闭时发生的次要异常。
两者语义不同：一个是因果关系，一个是并发失败的附属信息。调试时需同时检查 getCause() 和 getSuppressed() 才能还原完整现场。
- 因果异常通常出现在自定义异常构造器中：
new ServiceException(msg, originalEx) - suppressed 异常只在 try-with-resources 中出现，且仅当主异常已存在时才被压制
- 日志框架（如 Logback）默认不打印 suppressed 异常，需显式配置或手动遍历输出
catch 块里，而在 finally 的关闭逻辑、日志埋点前的异常包装、以及跨层服务调用时对 checked/unchecked 的随意转换。 
