方法参数校验与IllegalArgumentException详解

本文深入剖析了IllegalArgumentException的正确使用哲学：它不是被动捕获的异常，而是方法作者主动亮出的“拒收单”，用于在方法入口处精准拦截逻辑非法的输入参数；强调校验必须前置、错误信息须包含参数名、实际值和明确业务范围，并严格区分其与NullPointerException等异常的语义边界；特别警示构造函数中校验不可遗漏，避免带病对象污染后续流程；同时明确指出该异常不应被业务层随意捕获掩盖，而应作为清晰的责任信号直达调用方，推动问题在源头暴露和修正——真正考验的，是每次写if判断时那多想半秒的工程自觉。

IllegalArgumentException 是谁该负责的异常？

它不是运行时意外，而是你——方法作者——主动扔出来的“拒收单”。当调用方传了逻辑上不成立的值（比如 timeoutMs = -1、status = "unknown"、id = null 但契约要求非空），你就该在方法最开头拦住它，抛 IllegalArgumentException。这不是替调用方兜底，是明确划清责任边界：错不在执行过程，而在输入本身。

怎么写才不算白抛？

光 throw new IllegalArgumentException("参数错了") 没用，调用方根本没法修。关键是要让错误消息自带诊断信息：

• 包含参数名和实际值："maxRetries must be positive, but was: -3"，而不是 "invalid parameter"
• 注明来源（尤其配置驱动场景）："from @Value('${cache.ttl.seconds}')"
• 避免模糊范围描述："age must be between 0 and 150" 比 "age is invalid" 有用十倍
• 别把 NullPointerException 和它混用：对 null 做校验，优先用 Objects.requireNonNull(param, "param") —— 它抛的是 NullPointerException，语义更精准

构造函数里最容易漏掉校验

DTO、实体类、配置类的构造函数，是参数合法性第一道也是最后一道闸门。一旦放行非法值，对象就带病出生，后面所有方法都可能在奇怪的地方崩，堆栈还找不到源头。

示例（正确姿势）：

public User(String name, int age) {
    if (name == null || name.trim().isEmpty()) {
        throw new IllegalArgumentException("name cannot be null or blank");
    }
    if (age  150) {
        throw new IllegalArgumentException("age must be between 0 and 150, but was: " + age);
    }
    this.name = name;
    this.age = age;
}

别依赖 Lombok 的 @NonNull —— 它生成的是 NullPointerException，且无法表达业务约束（比如“非空但也不能是空白字符串”）。

哪些地方不该 catch 它？

IllegalArgumentException 是信号灯，不是交通锥。你在业务流程里 try-catch 它并吞掉、重试或 fallback，等于把“用户输错了”当成“网络抖动”来处理。

• Controller 层收到非法请求参数？让它 400 掉，前端立刻修正
• Service 方法被传了非法 ID？直接向上冒泡，让调用方（通常是 Controller 或测试用例）看见问题
• 唯一合理捕获场景：你封装了一个通用工具方法，且明确承诺“失败则返回默认值”，比如 parseDuration(String s) 可以 catch 后返回 Duration.ZERO，但必须文档写清

真正难的从来不是怎么抛，是怎么让每个抛出点都带着上下文、不越界、不替代其他异常语义——这需要在每次写 if 判断时，多想半秒“这个错，到底该怪谁”。

以上就是《方法参数校验与IllegalArgumentException详解》的详细内容，更多关于的资料请关注golang学习网公众号！