throws是Java中声明受检异常的语法，强制调用方处理IOException等checked exception，不适用于RuntimeException；子类重写时只能缩小不能扩大异常范围，核心在于按分层职责决定异常处理位置。
throws 是给调用者签的一份“异常责任书”
它不处理异常，只明确告诉调用方：“我这个方法可能会抛出 IOException 或 SQLException，你得自己接住，别怪我没提醒。” 编译器会强制检查——如果方法声明了受检异常（checked exception）但调用处既没 try-catch，也没继续 throws，代码直接编译失败。
- 只对受检异常（如
IOException、ClassNotFoundException）生效；RuntimeException及其子类（如NullPointerException）写了也白写，编译器不管 - 不是“可能出错才写”，而是“调用了会抛受检异常的 API 就必须写”——比如
new FileInputStream()本身就会抛FileNotFoundException，你就绕不开 - 声明多个异常时用逗号分隔：
throws IOException, SQLException，顺序无关，但建议按常见程度或业务层级从具体到宽泛排
什么时候该用 throws，而不是自己 try-catch？
核心判断标准是：当前方法是否适合做异常决策。比如工具类里的 readFile() 方法，它只负责读，不知道该重试、该提示用户、还是该记录日志——这些逻辑属于业务层，不该塞进工具方法里。
- ✅ 推荐用
throws的场景：
– 方法封装了文件/网络/数据库等外部资源操作
– 公共 API 需要暴露错误语义（如parseJson(String)声明throws JsonParseException）
– 分层架构中，DAO 层异常向上透传给 Service 层统一处理 - ❌ 别滥用
throws的情况：
– 参数校验失败（如年龄为负），该用throw new IllegalArgumentException()立即中断，而不是声明再让上层处理
– 私有方法能当场关掉资源（比如关闭BufferedReader），就别把IOException往外推
子类重写时 throws 写错会编译报错
Java 强制要求：子类重写父类方法时，throws 的异常范围不能比父类更宽。比如父类声明 throws IOException，子类可以不写 throws，也可以写 throws FileNotFoundException（它是 IOException 的子类），但绝不能写 throws Exception 或 throws SQLException。
ImageMagick 批处理处理器
下载
使用 ImageMagick 的 convert 和 mogrify 命令进行批量图像处理，支持调整大小、裁剪、水印和格式转换。与 libvips 集成以实现高性能缩略图生成。
- 这是为了保障多态安全——调用方按父类契约写好
catch(IOException e)，结果子类突然抛出SQLException，那就没人接得住 - 接口方法若声明了
throws，所有实现类都必须遵守同一约束，哪怕你内部根本没 IO 操作，也得在签名里留着（或抛更具体的子类） - 如果真需要扩展异常类型，正确做法是定义新的受检异常类，让它继承原有异常，再在子类中声明抛出这个新类型
常见坑：声明了 throws，却忘了调用方怎么接
很多人写了 public static void doWork() throws IOException 就以为完事了，结果在 main() 里直接调用，IDE 红标一片。最省事的解法不是到处加 try-catch，而是让调用链顶层承担兜底责任：
立即学习“Java免费学习笔记（深入）”；
- 命令行程序：在
main(String[] args) throws IOException上继续声明，交给 JVM 打印堆栈（适合脚本类小工具） - Web 应用：Controller 方法声明
throws ServiceException，由全局异常处理器（@ControllerAdvice）统一转成 HTTP 状态码和 JSON 错误体 - 千万别把
throws Exception当万金油——它掩盖了真实错误类型，调用方无法针对性处理，后期排查成本陡增
真正难的从来不是写 throws，而是想清楚哪一层该感知这个异常、以什么形式反馈、要不要转换语义。一个声明背后，其实是整个调用链的责任切分。
