Java方法参数空值校验最佳实践：方法内还是调用前校验？

Great question—this is a super common pitfall in Java development, and getting it right saves tons of debugging time later. Let’s break down your options and land on the best approach.

First, the core principle here: a method should be responsible for validating its own inputs (defensive programming). Relying on callers to do null checks is risky—you can’t guarantee every future developer (including future you!) will remember to validate before calling. And when something goes wrong, you want the error to be as clear and immediate as possible.

Let’s walk through your three methods:

• 方法1: This is problematic because if either obj1 or obj2 is null, the method just does nothing silently. The caller will have no idea their input was invalid, leading to confusing "nothing happens" bugs that are a nightmare to trace. Avoid this at all costs.

• 方法2: Skipping validation entirely means you’ll likely get a NullPointerException somewhere in your logic—but this exception won’t tell you which parameter was null. The stack trace might point to a line deep in your method, forcing the caller to reverse-engineer what went wrong. Not ideal.

• 方法3: This is the right foundation, but we can tweak it to be even better. The key issue with your current version is using && (so if obj1 is null, we never check obj2) and throwing a generic Exception. Instead, split the checks and throw specific, descriptive exceptions:

void method(Object obj1, Object obj2) {
    if (obj1 == null) {
        throw new IllegalArgumentException("obj1 must not be null");
    }
    if (obj2 == null) {
        throw new IllegalArgumentException("obj2 must not be null");
    }
    // Your core logic here
}

This improved version fixes exactly what you’re worried about: if a caller passes a null, they get an immediate, specific error telling them exactly which parameter is missing. No guessing, no silent failures, no vague NPEs.

Why is internal validation better than pre-call checks? Because your method becomes self-contained and robust. It doesn’t depend on external code to behave correctly, and it communicates its requirements clearly through exceptions. This is especially critical if your method is part of a public API, shared library, or used by multiple team members.

To sum up: Opt for an improved version of Method 3—validate each parameter individually inside the method, and throw descriptive IllegalArgumentExceptions (or custom validation exceptions if needed) when nulls are detected.

内容的提问来源于stack exchange，提问作者ksv