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

如果它是一个setter方法，并且null被传递给它，我认为抛出一个IllegalArgumentException会更有意义。NullPointerException似乎在尝试实际使用null的情况下更有意义。

如果你在使用它，它是空的，NullPointer。如果它被传入并且它为空，则为非法参数。

我倾向于遵循JDK库的设计，特别是集合和并发(Joshua Bloch, Doug Lea，这些人知道如何设计可靠的api)。不管怎样，JDK中的许多api都会主动抛出NullPointerException。

例如，Javadoc For Map。containsKey状态:

如果键为空，则@抛出NullPointerException 不允许空键(可选)。

举办自己的NPE是完全合理的。约定是在异常消息中包含为空的参数名。

模式是这样的:

public void someMethod(Object mustNotBeNull) {  
    if (mustNotBeNull == null) {  
        throw new NullPointerException("mustNotBeNull must not be null");  
    }  
}

无论您做什么，都不要允许设置一个错误的值，并在其他代码尝试使用它时抛出异常。这使得调试成为一场噩梦。你应该始终遵循“快速失败”的原则。

如果您选择抛出NPE，并且在方法中使用参数，显式检查null可能是多余的和昂贵的。我想VM已经为你做了。

公认的做法是使用IllegalArgumentException(字符串消息)来声明一个参数是无效的，并给出尽可能多的细节…所以说，一个参数被发现是空的，而异常是非空的，你会这样做:

if( variable == null )
    throw new IllegalArgumentException("The object 'variable' cannot be null");

你几乎没有理由隐式地使用“NullPointerException”。NullPointerException是当您试图在空引用(如toString())上执行代码时由Java虚拟机抛出的异常。

标准是抛出NullPointerException。通常不会出错的“有效Java”在第42项(第一版)、第60项(第二版)或第72项(第三版)中简要讨论了这一点。“赞成使用标准异常”:

可以说，都是错误的方法 调用归结为非法 争论或非法国家，但其他 异常通常用于 一些不合法的论点 州。如果调用方传入null 某个参数，其值为空 是被禁止的吗 NullPointerException被抛出 而不是IllegalArgumentException。”

以上两个例外的链接定义如下 IllegalArgumentException:抛出该异常，表示方法被传递了一个非法或不适当的参数。 NullPointerException:当应用程序试图在需要对象的情况下使用null时抛出。

这里最大的区别是IllegalArgumentException应该在检查方法的参数是否有效时使用。当一个对象被“使用”为空时，就应该使用NullPointerException。

我希望这能帮助你正确看待这两者。

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

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

我的2美分

如果它是一个“setter”，或者我要获取一个成员稍后使用的地方，我倾向于使用IllegalArgumentException。

如果它是我现在要在方法中使用(解引用)的东西，我主动抛出一个NullPointerException。我更喜欢这样做，而不是让运行时来做，因为我可以提供有用的消息(似乎运行时也可以这样做，但这是另一天的咆哮)。

如果我重写一个方法，我使用被重写的方法使用的任何东西。

一般来说，开发人员不应该抛出NullPointerException异常。当代码试图解引用值为null的变量时，运行时将引发此异常。因此，如果你的方法想要显式禁止null，而不是恰好有一个空值引发一个NullPointerException，你应该抛出一个IllegalArgumentException。

你应该使用IllegalArgumentException (IAE)，而不是NullPointerException (NPE)，原因如下:

首先，NPE JavaDoc显式地列出了适用于NPE的情况。请注意，当不恰当地使用null时，所有这些都是由运行时抛出的。相比之下，IAE JavaDoc再清楚不过了:“抛出是为了表明一个方法被传递了一个非法或不适当的参数。”没错，就是你!

其次，当您在堆栈跟踪中看到NPE时，您会假设什么?可能有人解引用了一个null。当您看到IAE时，您假定堆栈顶部的方法调用方传递了一个非法值。同样，后一种假设是正确的，前一种假设具有误导性。

第三，由于IAE显然是为验证参数而设计的，因此必须假设它是默认的异常选择，那么为什么要选择NPE呢?当然不是针对不同的行为——你真的期望调用代码分别捕获NPE和IAE，并因此做一些不同的事情吗?您是否试图传达更具体的错误消息?但是无论如何，您都可以在异常消息文本中这样做，就像处理所有其他不正确的参数一样。

第四，其他所有不正确的参数数据都会被IAE，为什么不一致呢?为什么非法null是如此特殊，以至于它应该从所有其他类型的非法参数中获得一个单独的异常?

最后，我接受其他答案给出的论点，即Java API的某些部分以这种方式使用NPE。然而，从异常类型到命名约定，Java API与所有内容都不一致，因此我认为仅仅盲目地复制(您最喜欢的部分)Java API并不是一个足以胜过这些其他考虑因素的好理由。

您应该抛出一个IllegalArgumentException，因为这将使程序员清楚地知道他做了一些无效的事情。开发人员太习惯于看到VM抛出的NPE，以至于任何程序员都不会立即意识到自己的错误，并开始随机查看，或者更糟糕的是，指责你的代码“有bug”。

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

在这种情况下，IllegalArgumentException使用API向用户传达了“不应该为空”的明确信息。正如其他论坛用户指出的那样，只要你使用API向用户传达正确的信息，你就可以使用NPE。

GaryF和tweak放弃了“有效Java”(我发誓)的参考，建议使用NPE。看看其他好的API是如何构造的，这是了解如何构造你的API的最好方法。

Another good example is to look at the Spring APIs. For example, org.springframework.beans.BeanUtils.instantiateClass(Constructor ctor, Object[] args) has a Assert.notNull(ctor, "Constructor must not be null") line. org.springframework.util.Assert.notNull(Object object, String message) method checks to see if the argument (object) passed in is null and if it is it throws a new IllegalArgumentException(message) which is then caught in the org.springframework.beans.BeanUtils.instantiateClass(...) method.

我想从其他非法参数中挑出Null参数，所以我从IAE派生了一个名为NullArgumentException的异常。甚至不需要读取异常消息，我就知道一个空参数被传递到一个方法中，并且通过读取消息，我找到了哪个参数为空。我仍然用IAE处理程序捕获NullArgumentException，但在我的日志中，我可以快速看到差异。

Apache Commons Lang有一个NullArgumentException，它完成了这里讨论的许多事情:它扩展了IllegalArgumentException，并且它唯一的构造函数采用了参数的名称，而参数的名称本应该是非空的。

虽然我觉得抛出NullArgumentException或IllegalArgumentException之类的异常更准确地描述了异常情况，但我和同事们还是选择遵从Bloch在这个问题上的建议。

给杰森·科恩的论点投了一票，因为它表现得很好。让我一步一步地分解它。: -)

The NPE JavaDoc explicitly says, "other illegal uses of the null object". If it was just limited to situations where the runtime encounters a null when it shouldn't, all such cases could be defined far more succinctly. Can't help it if you assume the wrong thing, but assuming encapsulation is applied properly, you really shouldn't care or notice whether a null was dereferenced inappropriately vs. whether a method detected an inappropriate null and fired an exception off. I'd choose NPE over IAE for multiple reasons It is more specific about the nature of the illegal operation Logic that mistakenly allows nulls tends to be very different from logic that mistakenly allows illegal values. For example, if I'm validating data entered by a user, if I get value that is unacceptable, the source of that error is with the end user of the application. If I get a null, that's programmer error. Invalid values can cause things like stack overflows, out of memory errors, parsing exceptions, etc. Indeed, most errors generally present, at some point, as an invalid value in some method call. For this reason I see IAE as actually the MOST GENERAL of all exceptions under RuntimeException. Actually, other invalid arguments can result in all kinds of other exceptions. UnknownHostException, FileNotFoundException, a variety of syntax error exceptions, IndexOutOfBoundsException, authentication failures, etc., etc.

总的来说，我觉得NPE受到了很大的诋毁，因为传统上一直与未能遵循快速失效原则的代码联系在一起。再加上JDK未能用消息字符串填充NPE，这确实产生了一种强烈的负面情绪，这种情绪是没有根据的。实际上，从运行时的角度来看，NPE和IAE之间的区别仅限于名称。从这个角度来看，你的名字越精确，你给调用者的信息就越清晰。

我完全赞成为空参数抛出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.

二分法……它们不重叠吗?只有整体中不重叠的部分才能构成二分法。在我看来:

throw new IllegalArgumentException(new NullPointerException(NULL_ARGUMENT_IN_METHOD_BAD_BOY_BAD));

一些集合假设使用NullPointerException而不是IllegalArgumentException拒绝null。例如，如果你比较一个包含null的集合和一个拒绝null的集合，第一个集合将调用另一个集合的containsAll，并捕获它的NullPointerException——而不是IllegalArgumentException。(我正在查看AbstractSet.equals的实现。)

You could reasonably argue that using unchecked exceptions in this way is an antipattern, that comparing collections that contain null to collections that can't contain null is a likely bug that really should produce an exception, or that putting null in a collection at all is a bad idea. Nevertheless, unless you're willing to say that equals should throw an exception in such a case, you're stuck remembering that NullPointerException is required in certain circumstances but not in others. ("IAE before NPE except after 'c'...")

类似地，构建工具可以自动插入空检查。值得注意的是，Kotlin的编译器在向Java API传递可能为空的值时执行此操作。当检查失败时，结果是NullPointerException。因此，为了给所有的Kotlin用户和Java用户提供一致的行为，您需要使用NullPointerException。

抛出一个排除空参数的异常(无论是NullPointerException还是自定义类型)使得自动化空测试更加可靠。这种自动化测试可以通过反射和一组默认值来完成，就像在Guava的NullPointerTester中一样。例如，NullPointerTester将尝试调用以下方法…

Foo(String string, List<?> list) {
  checkArgument(string.length() > 0);
  // missing null check for list!
  this.string = string;
  this.list = list;
}

...with two lists of arguments: "", null and null, ImmutableList.of(). It would test that each of these calls throws the expected NullPointerException. For this implementation, passing a null list does not produce NullPointerException. It does, however, happen to produce an IllegalArgumentException because NullPointerTester happens to use a default string of "". If NullPointerTester expects only NullPointerException for null values, it catches the bug. If it expects IllegalArgumentException, it misses it.

实际上，在我看来，抛出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.

根据您的场景，IllegalArgumentException是最好的选择，因为null不是属性的有效值。

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

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

理想情况下，不应该抛出运行时异常。应该为您的场景创建一个受控异常(业务异常)。因为如果这些异常中的任何一个被抛出并记录下来，它就会误导开发人员在查看日志时。相反，业务异常不会造成这种恐慌，并且在故障排除日志时通常会被忽略。

作为一个主观问题，这应该是封闭的，但它仍然是开放的:

这是我以前工作的地方使用的内部政策的一部分，效果非常好。这些都是我的记忆，所以我不记得确切的措辞。值得注意的是，他们没有使用受控异常，但这超出了问题的范围。他们使用的未检查异常主要分为3类。

NullPointerException:不故意抛出。npe只有在解引用空引用时才会被VM抛出。要尽一切可能的努力确保这些错误永远不会被抛出。@Nullable和@NotNull应该与代码分析工具一起使用来发现这些错误。

IllegalArgumentException:当函数的参数不符合公共文档时抛出，这样就可以根据传入的参数识别和描述错误。OP的情况就属于这一类。

IllegalStateException:当调用函数时，其实参在传递时是意外的，或者与方法所属对象的状态不兼容时抛出。

例如，在有长度的事物中使用IndexOutOfBoundsException的两个内部版本。一个是IllegalStateException的子类，在索引大于长度时使用。另一个是IllegalArgumentException的子类，用于索引为负的情况。这是因为您可以向对象添加更多的项，并且参数将是有效的，而负数永远无效。

正如我所说，这个系统工作得非常好，有人解释了为什么会有这样的区别:“根据错误的类型，你很容易就能弄清楚该怎么做。即使您无法真正找出出错的地方，也可以找出在哪里捕获错误并创建额外的调试信息。”

NullPointerException:处理Null情况或放入断言，这样NPE就不会被抛出。如果你输入的断言只是另外两种类型中的一种。如果可能，继续调试，就像断言一开始就在那里一样。

IllegalArgumentException:你的调用站点有错误。如果传入的值来自另一个函数，请查明为什么接收到不正确的值。如果传入一个参数，则会在调用堆栈中进行错误检查，直到找到没有返回预期值的函数。

您没有按照正确的顺序调用函数。如果您正在使用其中一个参数，请检查它们并抛出IllegalArgumentException描述该问题。然后，您可以在堆栈上传播腮部，直到找到问题。

不管怎样，他的观点是你只能把IllegalArgumentAssertions复制到堆栈上。您无法将illegalstateexception或nullpointerexception传播到堆栈上，因为它们与您的函数有关。