Question

给定像这样的通用界面（它不是我的实际情况，但作为最小例子）：

/** Generic interface for unary functions on strings. */
public interface StringTransformer {
  /**
   * Transform the given non-null string.
   * @param x string to be transformed
   * @return transformed string
   * @throws NullPointerException if x is null
   */
   String apply(String x);
}

假设我有一个返回常量值的实现，无论传递的参数如何：

public class EmptyAllStrings implements StringTransformer {
  public String apply(String x) {
    return "";
  }
}

我怀疑的是，如果参数是null，添加一个检查来抛出NPE是否是个好主意，即使在这种情况下无关紧要。

  public String apply(String x) {
    Objects.checkNotNull(x);
    return "";
  }

反对检查的要点：

null可用于已知使用的特定类
少代码

支持检查的要点：

有效地符合界面javadoc
可能有助于发现null相关的错误，即使使用null - 弹性类也是如此

是否有更多或更少的权威＆＃34;指南建议这样的情况中的两个选项之一？

Answer 1

我不明白你为什么要在这里检查null。我的想法是JVM抛出NullPointerException，而不是Java代码...如果有的话，我希望为这种检查抛出一个IllegalArgumentException（虽然我和人一起工作过谁是不同的意见，所以YMMV）。

但是，你可以从零开始有效地归还一些东西;你不知道周围的代码是否需要null检查。这不是代码的责任。

Javadoc评论意味着“可能会抛出异常”，而不是“保证”IMO。

Answer 2

我实际上已经看过几次这样做了，我总是有一个问题“为什么？”，基本上它是糟糕的开发，因为其他人已经说过它不是应该抛出JVM所在的NPE的代码， NPE是开发人员错误。有一个总是返回相同的东西的实现方法是没有意义的，不需要所以应该删除，否则提供一个正确的实现，并进行空检查（如果有可能参数可能为null）抛出带有消息和句柄的IllegalArgumentEx其他地方正确。

Answer 3

我认为问题的根源是接口文档中存在@throws NullPointerException。 NullPointerException应该用于编程错误，但在这里你只是陈述合同，而不是实现。让实现类决定如何处理空值，并相应地调整文档。

如果接口代码是给定且不可更改的，那么在我看来你可以：

检查null，即使您不使用参数（首选）或;
覆盖子类中的文档，声明您的实现不会以任何方式使用该参数，甚至不用于检查。

是否应该对未使用的参数进行空值检查？

3 个答案: