java.lang.IllegalArgumentException：那个最容易被忽略，却最该被重视的异常

网罗开发（小红书、快手、视频号同名）

大家好，我是展菲，目前在上市企业从事人工智能项目研发管理工作，平时热衷于分享各种编程领域的软硬技能知识以及前沿技术，包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。

图书作者：《ESP32-C3 物联网工程开发实战》
图书作者：《SwiftUI 入门，进阶与实战》
超级个体：COC上海社区主理人
特约讲师：大学讲师，谷歌亚马逊分享嘉宾
科技博主：华为HDE/HDG

我的博客内容涵盖广泛，主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告，同时也会提供产品优缺点分析、横向对比，并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。

展菲：您的前沿技术领航员
👋 大家好，我是展菲！
📱 全网搜索“展菲”，即可纵览我在各大平台的知识足迹。
📣 公众号“Swift社区”，每周定时推送干货满满的技术长文，从新兴框架的剖析到运维实战的复盘，助您技术进阶之路畅通无阻。
💬 微信端添加好友“fzhanfei”，与我直接交流，不管是项目瓶颈的求助，还是行业趋势的探讨，随时畅所欲言。
📅 最新动态：2025 年 3 月 17 日
快来加入技术社区，一起挖掘技术的无限潜能，携手迈向数字化新征程！

文章目录

- 前言
- IllegalArgumentException 到底在表达什么
- 一个真实又常见的踩坑场景
- - 问题不是“会不会报错”，而是“错得太安静”
- 正确的第一步：主动校验方法参数
- - 为什么这是“工程级写法”
- 使用 Objects.requireNonNull，不只是防空指针
- 参数之间的“隐形规则”，更容易出问题
- 用单元测试，把参数边界一次性卡死
- - 建议重点覆盖哪些边界
- IllegalArgumentException 的正确使用边界
- 总结

前言

如果你写 Java 写得够久，一定见过这个异常：

java.lang.IllegalArgumentException

它不像NullPointerException那样“臭名昭著”，
也不像IndexOutOfBoundsException那样一眼就能看懂。

但它有一个特点：
一旦在生产环境出现，往往意味着代码在“默默放水”。

这篇文章我们就从真实场景出发，聊清楚三个问题：

它到底在什么时候该抛？
为什么很多代码“该抛没抛”
怎样把它用成一条“工程安全线”

IllegalArgumentException 到底在表达什么

一句话概括：

方法被调用了，但你传进来的参数不在我能接受的范围内。

注意，这里有两个关键信息：

方法本身是“能执行的”
问题出在「参数合法性」，而不是系统状态

举几个非常常见的场景：

数量不能为负数
枚举值不在约定范围
字符串格式不符合业务规则
参数之间存在约束关系，但没人校验

这些问题，编译期发现不了，运行期不拦就会一路放行。

一个真实又常见的踩坑场景

假设你在写一个很普通的下单逻辑：

publicclassOrderService{publicvoidcreateOrder(intquantity){// 业务处理System.out.println("创建订单，数量："+quantity);}}

看起来没毛病，对吧？

但如果调用方传了这样一个参数：

createOrder(-3);

代码能跑，日志也正常输出，但语义已经彻底错了。

问题不是“会不会报错”，而是“错得太安静”

数据已经污染
下游系统还会继续处理
最后出问题时，很难定位源头

这正是 IllegalArgumentException 应该出现的地方。

正确的第一步：主动校验方法参数

最直接、也是最推荐的方式，就是在方法入口处明确校验。

publicvoidcreateOrder(intquantity){if(quantity<=0){thrownewIllegalArgumentException("quantity must be greater than 0");}System.out.println("创建订单，数量："+quantity);}

这里有几个细节值得注意：

校验逻辑放在方法最前面
异常信息要能直接定位问题
不要指望“调用方一定会传对”

为什么这是“工程级写法”

因为它把错误：

挡在了业务逻辑之前
固定在了最小范围内
让错误在第一次发生时就暴露

使用 Objects.requireNonNull，不只是防空指针

很多人以为Objects.requireNonNull只是用来防 NPE，其实它更适合用在：

参数不允许为空的明确约束上

来看一个更真实的例子。

importjava.util.Objects;publicclassUserService{publicvoidupdateUserName(StringuserId,Stringname){Objects.requireNonNull(userId,"userId must not be null");Objects.requireNonNull(name,"name must not be null");System.out.println("更新用户 "+userId+" 的名称为："+name);}}

相比手写if (xxx == null)，它有几个好处：

表意非常清晰
异常类型统一
错误信息集中在方法入口

更重要的是：代码读起来像一份“参数契约”。

参数之间的“隐形规则”，更容易出问题

很多参数问题，并不是单个值非法，而是组合不合法。

比如这样一个场景：

publicvoidrefund(intamount,booleanisPartial){if(isPartial&&amount<=0){thrownewIllegalArgumentException("partial refund amount must be greater than 0");}System.out.println("退款金额："+amount);}

这里如果不校验：

isPartial = true
amount = 0

逻辑上完全说不通，但代码却能正常跑。

这种问题：

不好排查
不容易写测试
最容易在业务变复杂后出事故

IllegalArgumentException 在这里就是一道“逻辑保险丝”。

用单元测试，把参数边界一次性卡死

如果你只在代码里校验，但没有测试，迟早会被“重构误删”。

来看一个 JUnit 示例：

importorg.junit.jupiter.api.Test;importstaticorg.junit.jupiter.api.Assertions.assertThrows;publicclassOrderServiceTest{@TestvoidshouldThrowExceptionWhenQuantityIsInvalid(){OrderServiceservice=newOrderService();assertThrows(IllegalArgumentException.class,()->{service.createOrder(0);});assertThrows(IllegalArgumentException.class,()->{service.createOrder(-1);});}}