实际上，在我看来，抛出IllegalArgumentException或NullPointerException的问题只是对Java中不完全理解异常处理的少数人的“圣战”。一般来说，规则很简单，如下:

argument constraint violations must be indicated as fast as possible (-> fast fail), in order to avoid illegal states which are much harder to debug in case of an invalid null pointer for whatever reason, throw NullPointerException in case of an illegal array/collection index, throw ArrayIndexOutOfBounds in case of a negative array/collection size, throw NegativeArraySizeException in case of an illegal argument that is not covered by the above, and for which you don't have another more specific exception type, throw IllegalArgumentException as a wastebasket on the other hand, in case of a constraint violation WITHIN A FIELD that could not be avoided by fast fail for some valid reason, catch and rethrow as IllegalStateException or a more specific checked exception. Never let pass the original NullPointerException, ArrayIndexOutOfBounds, etc in this case!

至少有三个非常好的理由反对将所有类型的参数约束违反映射到IllegalArgumentException，第三个理由可能非常严重，以至于标志着这种做法的糟糕风格:

(1) A programmer cannot a safely assume that all cases of argument constraint violations result in IllegalArgumentException, because the large majority of standard classes use this exception rather as a wastebasket if there is no more specific kind of exception available. Trying to map all cases of argument constraint violations to IllegalArgumentException in your API only leads to programmer frustration using your classes, as the standard libraries mostly follow different rules that violate yours, and most of your API users will use them as well!

(2) Mapping the exceptions actually results in a different kind of anomaly, caused by single inheritance: All Java exceptions are classes, and therefore support single inheritance only. Therefore, there is no way to create an exception that is truly say both a NullPointerException and an IllegalArgumentException, as subclasses can only inherit from one or the other. Throwing an IllegalArgumentException in case of a null argument therefore makes it harder for API users to distinguish between problems whenever a program tries to programmatically correct the problem, for example by feeding default values into a call repeat!

(3) Mapping actually creates the danger of bug masking: In order to map argument constraint violations into IllegalArgumentException, you'll need to code an outer try-catch within every method that has any constrained arguments. However, simply catching RuntimeException in this catch block is out of the question, because that risks mapping documented RuntimeExceptions thrown by libery methods used within yours into IllegalArgumentException, even if they are no caused by argument constraint violations. So you need to be very specific, but even that effort doesn't protect you from the case that you accidentally map an undocumented runtime exception of another API (i.e. a bug) into an IllegalArgumentException of your API. Even the most careful mapping therefore risks masking programming errors of other library makers as argument constraint violations of your method's users, which is simply hillareous behavior!

With the standard practice on the other hand, the rules stay simple, and exception causes stay unmasked and specific. For the method caller, the rules are easy as well: - if you encounter a documented runtime exception of any kind because you passed an illegal value, either repeat the call with a default (for this specific exceptions are neccessary), or correct your code - if on the other hand you enccounter a runtime exception that is not documented to happen for a given set of arguments, file a bug report to the method's makers to ensure that either their code or their documentation is fixed.

这是一个“圣战”式的问题。换句话说，两种选择都是好的，但人们会有自己的偏好，他们会誓死捍卫这些偏好。

当试图访问具有当前值为null的引用变量的对象时，抛出NullPointerException。

当方法接收到格式与方法预期不同的参数时，抛出IllegalArgumentException。

我完全赞成为空参数抛出IllegalArgumentException，直到今天，当我注意到Java 7中的Java .util. objects . requirenonnull方法时。用这种方法，而不是做:

if (param == null) {
    throw new IllegalArgumentException("param cannot be null.");
}

你可以:

Objects.requireNonNull(param);

如果你传递给它的参数为空，它会抛出一个NullPointerException。

考虑到这个方法正好在java的中间。util我认为它的存在是一个非常强烈的迹象，抛出NullPointerException是“Java做事的方式”。

我想我已经决定了。

注意，关于硬调试的参数是虚假的，因为您当然可以向NullPointerException提供一条消息，说明什么是null，以及为什么它不应该是null。就像IllegalArgumentException。

One added advantage of NullPointerException is that, in highly performance critical code, you could dispense with an explicit check for null (and a NullPointerException with a friendly error message), and just rely on the NullPointerException you'll get automatically when you call a method on the null parameter. Provided you call a method quickly (i.e. fail fast), then you have essentially the same effect, just not quite as user friendly for the developer. Most times it's probably better to check explicitly and throw with a useful message to indicate which parameter was null, but it's nice to have the option of changing that if performance dictates without breaking the published contract of the method/constructor.

我完全同意你说的话。早失败，快失败。非常好的异常咒语。

抛出哪个Exception主要是个人喜好的问题。在我看来，IllegalArgumentException似乎比使用NPE更具体，因为它告诉我问题是我传递给方法的参数，而不是执行方法时可能生成的值。

我的2美分

如果你不希望null是一个允许的值，似乎会调用IllegalArgumentException，如果你试图使用一个结果为null的变量，则会抛出NullPointerException。