为什么总是遇到illegalargument错误？(三个常见原因你踩坑了吗)

被IllegalArgumentException搞疯的实践记录

妈的，最近被这个`IllegalArgumentException`搞得我头都大了。每次代码一跑起来，总是时不时给我来一下，气得我差点把键盘都砸了。以前我总觉得，这不就是传参不对吗？小问题，改改就得了。结果越深挖越发现，这玩意儿能踩的坑，那是真不少。我之前接手了一个老项目，那帮人代码写得叫一个奔放，各种参数校验跟闹着玩儿似的，导致系统隔三岔五就抽风。

我当时就对自己说，不行，非得把这几个最阴险的坑给揪出来不可。我撸起袖子，把最近半年生产环境的报错日志全拉了一遍，一行一行地对照、分类、总结，硬生生花了两个周末才算把这个“祖传烂坑”理出个头绪。最终，总算给我总结出了三个最常见的“罪状”，这东西真就是拿命换来的经验。

三大常见IllegalArgumentException的“罪状”

我的实践记录里，这三个问题是最频繁出现的，看你中招了没：

• 第一个：外部参数的“看起来对”陷阱

  最气人的就是这个。业务要求你传一个用户ID，你传过去了，格式也对，但它TMD是个负数！或者要求传一个列表，你传过去了，但列表里有个别元素是`null`。代码接收到参数后，只是笼统地看了眼，没做深入的业务校验，一执行到具体逻辑，比如计算、查找、数据库操作，就直接抛出IAE。解决办法：我要求团队所有接口的参数，都必须在接收那一刻就进行严格的业务语义校验，不只是非空校验这么简单。

  

• 第二个：边界值校验的缺位

  这个就是老程序员的粗心病。比如方法要求传入分页的页码`page`和大小`size`，多数人只判了非空。但如果有人传了个`page=0`（但业务要求从1开始），或者传了个`size=500`（但上限是100），系统内部的某些库或框架方法就会因为这个“非法”的值而爆炸。我把所有外部入参的边界值都写进校验工具类里，比如最小不能小于1，最大不能超过配置值，哪怕代码看起来多了一点，也比半夜被电话叫醒强。

• 第三个：老代码的“假想敌”空值问题

  

  这个就是历史遗留问题，特别是在微服务和多系统交互的地方。老代码可能压根没想过某些关键参数会是`null`，因为在以前的系统里它永远不会是空。结果现在新系统一接入，或者数据源一改动，就传了一个空值过来。老代码里的方法一调用，直接奔溃，抛出的就是IAE，因为它没法用这个`null`去做后续操作。我的做法是：凡是涉及到跨系统调用的，先把传进来的参数全打印一遍，然后强制对所有关键参数进行非空判断，哪怕是冗余的。

我为啥对这破错误如此上心

我为啥对这玩意儿这么上心，非得挖地三尺总结出来？因为前年我差点被这破错误搞得失业。当时我们接了个大客户的项目，合同都签了，就等上线。结果TMD上线前一天晚上，凌晨三点，系统突然崩了。日志里铺天盖地全是这I A E！我当时都懵了，汗把衣服都湿透了。

项目经理一个电话打过来，那声音，能把我耳朵震聋。他直接在电话里吼，说这个错误不解决，明天客户那边撤资，所有人年终奖都没了，让我直接卷铺盖滚蛋。我当时就跟我老婆说，完了，今年过年没钱了。那段时间，我连着三天住在公司，靠咖啡续命，眼睛熬得跟兔子一样。

我就是在那三天里，把我那老东家祖传下来的烂代码一行一行抠出来，才发现他们以前根本没做参数的严格校验，全是靠运气跑起来的！从那以后，我对这种基础错误就有了阴影，只要看到I A E，我就条件反射地要把它从根儿上刨出来。兄弟们，这分享的三个点，真是拿我差点失业的代价换来的，希望能帮你们避开这些操蛋的坑。