我有一个简单的setter方法的属性和空是不适合这个特定的属性。在这种情况下,我总是被撕裂:我应该抛出一个IllegalArgumentException,还是一个NullPointerException?从javadocs来看,两者都很合适。是否存在某种公认的标准?或者这只是其中一件事,你应该做任何你喜欢做的事情,两种都是正确的?


当前回答

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

其他回答

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

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

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

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

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

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

一般来说,开发人员不应该抛出NullPointerException异常。当代码试图解引用值为null的变量时,运行时将引发此异常。因此,如果你的方法想要显式禁止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.