throw用于方法内抛出异常实例，throws用于方法声明抛出异常类；受检异常必须声明或捕获，运行时异常可不声明；try-catch不自动恢复逻辑，空catch、宽泛捕获、丢失堆栈、finally中return覆盖结果均为常见错误；自定义异常需重写构造函数并确保getMessage有效。
throw 和 throws 的分工很明确
throw 用于在方法内部主动抛出一个异常对象，比如 throw new IllegalArgumentException("id 不能为负")；而 throws 是写在方法声明后面，表示这个方法可能把异常“甩出去”，由调用方处理，比如 public void readFile() throws IOException。
常见错误是混淆两者：在方法签名写了 throws，但方法体里没用 throw；或者用了 throw 却没在签名声明 throws（对受检异常而言），编译直接报错 Unhandled exception type XXXException。
-
throw后面跟的是异常实例，只能有一个 -
throws后面跟的是异常类名，可以并列多个，用逗号分隔 - 运行时异常（如
NullPointerException）可不声明throws，但受检异常（如IOException）必须声明或捕获
try-catch 块不是万能兜底
捕获异常的本质是“中断当前执行流，跳转到匹配的 catch 分支”，但它不会自动恢复业务逻辑。很多人以为加了 try-catch 就算处理完了，结果 catch 里只写了 e.printStackTrace()，日志没进文件、没告警、也没返回合理状态，问题照样在线上爆发。
典型误用场景：
立即学习“Java免费学习笔记（深入）”；
- 空
catch块（什么也不做）—— 异常被静默吞掉，后续逻辑基于错误状态继续执行 - 捕获太宽泛，比如
catch (Exception e)，掩盖了本该分开处理的业务异常和系统异常 - 在
catch中重新抛出新异常时，丢掉了原始堆栈，应优先用throw new XxxException("msg", e)
finally 里的 return 会覆盖 try/catch 中的 return
这是容易被忽略的控制流陷阱。只要 finally 块中有 return 语句，无论 try 或 catch 是否已执行过 return，最终方法返回值都是 finally 里的那个值。
示例：
public static int getValue() {
try {
return 1;
} catch (Exception e) {
return 2;
} finally {
return 3; // 实际返回的是 3，前两个 return 全被覆盖
}
}
- 避免在
finally中写return，除非你明确需要覆盖逻辑 - 资源释放（如
close()）应放在finally，但不要混入业务返回值 - JDK 7+ 推荐用 try-with-resources 替代手动
finally关闭，更安全也更简洁
自定义异常别忘了重写 getMessage 或构造函数
直接继承 Exception 或 RuntimeException 后，如果只写了个空构造函数，调用 e.getMessage() 得到的可能是 null，日志里就只剩个类名，排查时非常被动。
正确做法：
- 至少提供一个带
String message参数的构造函数，并调用super(message) - 如果需要携带上下文数据（如错误码、请求 ID），可额外加字段和 getter，但别忘了在
getMessage()中体现关键信息 - 区分场景：业务异常建议继承
RuntimeException（免得处处throws），系统级异常才用受检异常
复杂点在于异常链和分类粒度——同一类业务错误，是拆成多个子类（如 UserNotFoundException、UserStatusInvalidException），还是统一用一个 UserException 加错误码区分，得看团队对可观测性和维护成本的权衡。
