当存在后置条件时，方法的返回值不得为 null，该怎么办？
我可以做
assert returnValue != null : "Not acceptable null value";
但是断言可以关闭！
所以可以做吗
if(returnValue==null)
{
throw new NullPointerException("return value is null at method AAA");
}
?
或者，对于这样的条件，使用用户定义的异常（如NullReturnValueException）更好？
我建议你永远不要自己扔。NullPointerException
正如Thorbjørn Ravn Andersen在下面的评论中所说，不这样做的主要原因是，你不想将“真正的，坏的NPE”与故意抛出的NPE混合在一起。
因此，在您确信能够识别“有效”NPE 之前，我建议您在想要告知 API 用户这不是有效参数值时使用。应记录方法在传递非法 null 参数时的行为。IllegalArgumentExceptionnull
另一个（更现代的恕我直言）选项是在参数附近使用注释。这是一篇关于使用@NotNull注释的文章。@NotNull
正如我之前提到的，也可能有一些情况，当投掷NPE不会让你或你的队友感到困惑时：NPE原因应该是清晰和可识别的。
例如，如果你使用一些带有前置条件模块的库，比如，那么我发现使用-like方法是处理非法传递的空值的一种更可取的方法。GuavacheckNotNull()
checkNotNull(arg, msg)抛出NPE，但从堆栈跟踪中可以很清楚，它是由产生的，因此它不是一个未知的错误，而是预期的行为。Preconditions.checkNotNull()
我认为在JVM为您执行此操作之前尽早抛出NPE没有问题 - 特别是对于空参数。关于这一点似乎存在一些争论，但是在Java SE库中有很多例子可以做到这一点。我不明白为什么NPE应该在你自己无法投掷它方面是神圣的。
但是，我说点题外话。这个问题是关于不同的东西。您正在谈论一个后置条件，该条件声明返回值不得为 null。在这种情况下，null 肯定意味着你在方法中有一个错误？
您如何记录这一点？“此方法如果返回值意外为 null，则引发 NullPointerException”？没有解释这是怎么发生的？不，我会在这里使用断言。异常应该用于可能发生的错误 - 而不是涵盖如果方法内部出现问题时可能发生的事情，因为这对任何人都没有帮助。
