throw是抛出异常对象的语句，位于方法体内；throws是声明异常类型的关键字，位于方法签名末尾；前者用于触发异常，后者用于告知调用方可能抛出的受检异常。
throw 和 throws 的区别到底在哪
很多人写到一半发现编译报错，加了 throw new Exception() 却被 IDE 提示“Unhandled exception”，其实是混淆了 throw（抛出一个异常对象）和 throws（声明方法可能抛出的异常类型）。
-
throw是语句，只能出现在方法体内部，后面跟的是Exception实例，比如throw new IllegalArgumentException("id 不能为负") -
throws是方法签名的一部分，写在方法声明末尾，后面跟的是异常类名，可以多个，用逗号分隔，比如public void readFile() throws IOException, SecurityException - 只有受检异常（
Exception及其子类，但不包括RuntimeException）强制要求处理：要么用try-catch捕获，要么用throws声明上抛 -
RuntimeException及其子类（如NullPointerException、ArrayIndexOutOfBoundsException）属于非受检异常，编译器不强制处理，但运行时仍会中断流程
try-catch-finally 中哪些部分可以省略
catch 和 finally 都不能单独和 try 搭配；必须至少有一个。常见组合只有两种合法形式：try-catch 或 try-catch-finally（或 try-finally）。
-
try-finally合法，常用于确保资源释放，比如关闭FileInputStream，即使前面发生异常也要执行finally -
try-catch合法，用于拦截并处理异常，但要注意：如果catch里没重新抛出，异常就终止了，上层看不到 -
try块中 return 语句遇到finally时，会先执行finally再返回——但如果finally里也有 return，它会覆盖try或catch中的返回值 - JDK 7+ 支持 try-with-resources，自动关闭实现了
AutoCloseable的资源，比手写finally更安全，推荐优先使用
捕获异常时为什么不能只写 catch(Exception e)
看似“一网打尽”，实际会掩盖真正的问题，让调试变困难，也容易误吞本该向上抛的受检异常。
- 过度宽泛的
catch(Exception e)会捕获RuntimeException和所有受检异常，包括本不该在此处处理的IOException或SQLException - 如果业务逻辑明确知道只可能出
NumberFormatException，就该只捕获它，而不是用Exception包一层再忽略 - 多异常捕获从 JDK 7 开始支持语法糖：
catch (IOException | SQLException e)，比分别写两个catch更简洁，但前提是它们处理方式一致 - 日志记录时建议用
e.printStackTrace()仅用于调试；生产环境应使用logger.error("读取配置失败", e)，保留完整堆栈
自定义异常该继承 RuntimeException 还是 Exception
取决于你是否希望调用方**必须**处理它。这是设计契约，不是技术限制。
立即学习“Java免费学习笔记（深入）”；
- 继承
RuntimeException→ 非受检异常 → 调用方可选择处理或不处理，适合程序逻辑错误（如参数校验失败、状态非法），例如InvalidOrderStatusException - 继承
Exception→ 受检异常 → 编译器强制调用方处理，适合外部不确定性问题（如网络超时、文件不存在），例如PaymentTimeoutException（如果业务要求每个支付调用都显式应对超时） - 无论哪种，都建议提供至少两个构造函数：一个带
String message，一个带String message和Throwable cause，方便链式异常追踪 - 不要为了“看起来规范”而滥用受检异常——如果大多数调用方只会写
catch(Exception e) { throw new RuntimeException(e); }，那不如一开始定义成非受检的
public class InsufficientBalanceException extends RuntimeException {
public InsufficientBalanceException(String message) {
super(message);
}
public InsufficientBalanceException(String message, Throwable cause) {
super(message, cause);
}
}
异常机制不是用来代替 if 判断的，也不是为了让代码“看起来健壮”。关键在两点：该由谁处理、能否真正恢复。很多空 catch 块和泛化捕获，反而让故障更难定位。
