java异常传递靠throw抛出而非return返回，因异常是执行流中断而非计算结果，return会丢失堆栈、类型等关键信息，导致无法精准捕获和定位问题。
Java中异常信息传递给调用者，核心靠的是「抛出」而非「返回」——throw 语句把异常对象原样向上委托，由调用栈逐层回溯处理，不是靠方法返回值传递。
为什么不能用 return 返回异常信息
异常本质是程序执行流的非正常中断，不是计算结果。用 return 返回字符串或自定义错误对象，会丢失堆栈轨迹、异常类型、嵌套原因等关键上下文，调用方无法区分是业务失败还是系统故障，也无法做针对性捕获（比如只 catch IOException）。
常见错误现象：
– 写了 return "文件不存在"; 却在上层用 try-catch (FileNotFoundException e) 捕不到
– 把异常吞掉后返回 null，导致后续 NullPointerException 更难定位原始问题
正确做法始终是：遇到不可恢复的错误，构造并 throw 异常实例。
立即学习“Java免费学习笔记（深入）”；
checked 异常必须显式声明或处理
像 IOException、SQLException 这类 checked 异常，编译器强制你面对它——要么在方法签名加 throws 声明，要么用 try-catch 拦截。
- 声明方式：
public void readFile() throws IOException，调用方看到这个签名就必须处理 - 不声明又不捕获 → 编译失败，错误信息类似：
Unhandled exception type IOException - 若想“绕过”，只能包装成 unchecked 异常（如
throw new RuntimeException(e);），但会丢失原始类型语义
unchecked 异常可直接 throw，但别滥用
RuntimeException 及其子类（如 NullPointerException、IllegalArgumentException）不需要 throws 声明，可随时 throw，但它们代表的是编程错误或意外状态，不应作为常规业务错误传递手段。
使用场景举例：
– 参数校验失败：if (id <br>– 状态非法：<code>if (status == null) throw new IllegalStateException("status not initialized");
容易踩的坑：
– 用 RuntimeException 替代 IOException 隐藏 I/O 故障，导致调用方无法重试或降级
– 在 catch 块里只写 throw new RuntimeException(e);，丢掉了原始异常的 cause 和具体类型
推荐写法：throw new RuntimeException("读取配置失败", e); —— 第二个参数保留原始异常链。
异常链与 getCause() 是信息传递的关键载体
真实项目中，异常常被多层包装。比如 DAO 层抛 SQLException，Service 层转为 BusinessException，Controller 层再转为 ApiException。这时必须用带 cause 的构造函数，否则调用方调用 e.getCause() 会得到 null。
实操建议：
– 所有自定义异常类都提供 Exception(String message, Throwable cause) 构造器
– 包装时不要只传 message：throw new ServiceException("订单创建失败", e); ✅
– 错误示范：throw new ServiceException("订单创建失败"); ❌（原始异常丢失）
– 日志中打印完整链：log.error("操作失败", e);（SLF4J 会自动展开 cause）
性能提示：异常构造堆栈是开销点，但信息传递本身不耗资源；真正影响性能的是频繁抛出和捕获，不是包装本身。
最常被忽略的一点：异常信息是否可被调用方消费，取决于你有没有保留原始类型 + 堆栈 + cause。光有“友好提示”没用，调用方需要的是能区分、能响应、能追溯的异常对象，不是一句字符串。
