Java异常传播是JVM沿调用栈逐层上抛至首个匹配catch的过程；未捕获则线程终止。RuntimeException无需声明但照常传播，IOException必须声明或处理。finally抛异常会覆盖原异常，导致信息丢失。
Java中异常传播机制的本质，是JVM沿着方法调用栈（call stack）逐层向上查找第一个能处理该异常的catch块的过程；找不到就继续上抛，直到main方法或线程起点，最终未捕获则线程终止并打印堆栈。
异常怎么“往上走”：从抛出点到第一个匹配catch的路径
异常不是凭空跳转，而是严格按调用顺序逆向回溯：谁调用了抛出异常的方法，就交给谁处理；如果它没写catch，也不声明throws（对受检异常），编译直接报错；若写了throws但调用方也没处理，就继续往上调用方找。
-
throw发生在methodC()→ JVM立刻停止执行methodC剩余代码 - 检查
methodC所在try-catch：无匹配catch→ 异常对象被“带出”该方法 - 回到
methodB()中methodC()的调用位置，检查此处是否有包围它的try块 - 没有？继续回到
methodA()，再回到main()—— 整个过程是机械、确定、不可跳过的
为什么RuntimeException可以不声明，而IOException必须声明？
区别不在“能不能传播”，而在编译器是否强制你“交代去向”。RuntimeException及其子类属于非受检异常，编译器放行；IOException是受检异常，编译器要求你明确选择：要么try-catch吞掉，要么用throws甩给上层。
- 不声明
throws IOException却在方法里打开文件 → 编译失败，不是运行时才出问题 - 抛
NullPointerException从不需throws声明，但传播逻辑完全一样：照样沿栈上抛 - 混淆点：有人以为“不声明=不传播”，其实只是编译器不管，传播行为一模一样
finally里抛异常会覆盖原异常，这是真坑
当try块已抛出异常A，正要往外传时，finally块又抛出异常B —— JVM会丢弃A，只把B扔出去。原始错误信息就此丢失，排查时只剩一个“假凶器”。
ImageMagick 批处理处理器
下载
使用 ImageMagick 的 convert 和 mogrify 命令进行批量图像处理，支持调整大小、裁剪、水印和格式转换。与 libvips 集成以实现高性能缩略图生成。
立即学习“Java免费学习笔记（深入）”；
- 典型场景：
try里数据库查询失败抛SQLException，finally关连接时因网络抖动又抛IOException - 结果：堆栈里只看到
IOException，根本看不到SQL哪错了 - 安全做法：
finally里只做清理，避免任何可能抛异常的操作；真要处理，用if (resource != null) resource.close();+catch吞掉关闭异常
如何验证异常到底传到了哪一层？看堆栈最顶行的at
打印e.printStackTrace()后，第一行at后面的方法，就是异常最初抛出的位置；最后一行at（最底下），才是它最终落脚、被catch住的地方 —— 中间所有行，就是它一路经过却未被捕获的方法链。
- 堆栈里出现
at com.example.service.UserService.getUser(UserService.java:42)→ 异常起源于此 - 紧接着
at com.example.controller.UserController.handle(UserController.java:28)→ 这里没try，所以继续上传 - 最底下
at java.base/java.lang.Thread.run(Thread.java:833)→ 说明一直没人接，线程自己终结了 - 注意：IDE调试时，断点停在
throw那行，比看堆栈更直接——你亲眼看见它卡在哪一层
异常传播本身逻辑简单，难的是人在哪一层该拦截、哪一层该包装、哪一层该放行。最容易被忽略的，是finally悄悄吃掉原始异常，以及误以为“没写throws就不会传”——其实传得比谁都勤快。
