将 null 传递给方法

Question

我正在阅读优秀的干净的代码

其中一个讨论是关于传递空值进入一个方法。

public class MetricsCalculator {
    public double xProjection(Point p1, Point p2) {
        return (p2.x - p1.x) * 1.5;
    }
}
...
calculator.xProjection(null, new Point(12,13));

它代表了处理此问题的不同方式：

public double xProjection(Point p1, Point p2) {
    if (p1 == null || p2 == null) {
        throw new IllegalArgumentException("Invalid argument for xProjection");
    }
    return (p2.x - p1.x) * 1.5;
}

public double xProjection(Point p1, Point p2) {
    assert p1 != null : "p1 should not be null";
    assert p2 != null : "p2 should not be null";
    return (p2.x - p1.x) * 1.5;
}

我更喜欢 断言< /a> 方法，但我不喜欢默认情况下关闭断言的事实。

书中最后指出：

在大多数编程语言中，没有好的方法来处理调用者意外传递的 null。 因为是这种情况，所以合理的做法是默认禁止传递 null。

它并没有真正涉及您将如何执行此限制？

不管怎样，你们中有人有强烈的意见吗？

Answer 1

我更喜欢使用断言。

我有一条规则，只在公共和受保护的方法中使用断言。 这是因为我相信调用方法应该确保它将有效参数传递给私有方法。

Answer 2

尽管它并不严格相关，但您可能需要查看Spec#。

我认为它仍在开发中（由 Microsoft 开发），但有一些 CTP 可用，而且看起来很有前途。 基本上它允许您执行以下操作：

  public static int Divide(int x, int y)
    requires y != 0 otherwise ArgumentException; 
  {
  }

或者

  public static int Subtract(int x, int y)
    requires x > y;
    ensures result > y;
  {
    return x - y;
  } 

它还提供其他功能，例如 Notnull 类型。 它构建在 .NET Framework 2.0 之上并且完全兼容。 如您所见，语法是 C#。

Answer 3

@Chris Karcher 我想说绝对正确。 我唯一要说的是单独检查参数，并让异常报告为空的参数，因为它使得跟踪空值的来源变得更加容易。

@wvdschel 哇！ 如果编写代码对您来说太费力，您应该研究类似 PostSharp （或 Java 等效项）如果有的话）它可以对您的程序集进行后处理并为您插入参数检查。

Answer 4

由于离题似乎已成为主题，Scala 对此采取了一种有趣的方法。 所有类型都假定不为 null，除非您显式地将其包装在 Option 中以指示它可能为 null。 所以：

//  allocate null
var name : Option[String]
name = None

//  allocate a value
name = Any["Hello"]

//  print the value if we can
name match {
  Any[x] => print x
  _ => print "Nothing at all"
}

Answer 5

我通常不喜欢这样做，因为它只会减慢速度。 无论如何，稍后都会抛出 NullPointerException，这将很快导致用户发现他们将 null 传递给该方法。 我曾经检查过，但 40% 的代码最终都在检查代码，此时我认为不值得使用漂亮的断言消息。

Answer 6

我同意或不同意 wvdschel 的帖子，这取决于他具体说的内容。

当然，在这种情况下，此方法将在 null 上崩溃，因此可能不需要此处的显式检查。

但是，如果该方法只是存储传递的数据，并且稍后调用其他一些方法来处理它，那么尽早发现错误的输入是更快修复错误的关键。 到那时，可能会通过多种方式向您的班级提供不良数据。 这有点像试图弄清楚老鼠是如何在事后进入你的房子的，试图在某个地方找到洞。

Answer 7

以 Java 的方式，假设 null 来自编程错误（即永远不应该超出测试阶段），然后让系统抛出它，或者如果有达到该点的副作用，则在开始时检查 null 并抛出 IllegalArgumentException 或 NullPointerException。

如果 null 可能来自实际的异常情况，但您不想为此使用已检查的异常，那么您肯定希望在方法的开头使用 IllegalArgumentException 路由。

Answer 8

在大多数编程语言中，没有好的方法来处理调用者意外传递的 null。 因为是这种情况，所以合理的做法是默认禁止传递 null。

我发现 JetBrains 的 @Nullable 和 @NotNull 注释方法处理这个问题是迄今为止最巧妙的。 不幸的是，它是特定于 IDE 的，但在我看来确实干净且强大。

http://www.jetbrains.com/idea/documentation/howto.html

拥有这个（或类似的东西）作为 java 标准会非常好。

Answer 9

它并没有真正涉及您将如何执行此限制？

如果它们传入 null，则可以通过抛出 ArgumentException 来强制执行它。

if (p1 == null || p2 == null) {
    throw new IllegalArgumentException("Invalid argument for xProjection");
}

Answer 10

在我看来，在方法的开头抛出 C# ArgumentException 或 Java IllegalArgumentException 是最清晰的解决方案。

人们应该始终小心运行时异常 - 未在方法签名上声明的异常。 由于编译器不会强制您捕获这些内容，因此很容易忘记它们。 确保您有某种“捕获所有”异常处理，以防止软件突然停止。 这是用户体验中最重要的部分。

Answer 11

处理这个问题的最佳方法实际上是使用异常。 最终，断言最终将为最终用户提供类似的体验，但无法让开发人员在向最终用户显示异常之前调用您的代码来处理这种情况。 最终，您希望确保尽早测试无效输入（尤其是在面向公众的代码中）并提供调用代码可以捕获的适当异常。

Answer 12

有点偏离主题，但我认为 findbugs 的一个功能非常有用，就是能够注释方法的参数来描述哪些参数不应传递空值。

通过对代码进行静态分析，findbugs 可以指出使用可能为空值调用该方法的位置。

这有两个优点：

1. 注释描述了您对如何调用该方法的意图，辅助文档
2. FindBugs 可以指出该方法的潜在问题调用者，使您能够追踪潜在的错误。

仅当您有权访问调用您的方法的代码时才有用，但通常是这种情况。

Answer 13

也不是立即使用的，但与 Spec# 的提及有关...有一项建议在 Java 的未来版本中添加“空安全类型”："增强 null 处理 - Null 安全类型"。

根据该提案，您的方法将变为

public class MetricsCalculator {
    public double xProjection(#Point p1, #Point p2) {
        return (p2.x - p1.x) * 1.5;
    }
}

其中 #Point 是对 Point 类型对象的非 null 引用的类型。

Answer 14

Spec# 看起来很有趣！

当类似的东西不可用时，我通常使用运行时空检查和内部方法的断言来测试非私有方法。 我没有在每个方法中显式编码空检查，而是将其委托给具有检查空方法的实用程序类：

/**
 * Checks to see if an object is null, and if so 
 * generates an IllegalArgumentException with a fitting message.
 * 
 * @param o The object to check against null.
 * @param name The name of the object, used to format the exception message
 *
 * @throws IllegalArgumentException if o is null.
 */
public static void checkNull(Object o, String name) 
    throws IllegalArgumentException {
   if (null == o)
      throw new IllegalArgumentException(name + " must not be null");
}

public static void checkNull(Object o) throws IllegalArgumentException {
   checkNull(o, "object");
} 

// untested:
public static void checkNull(Object... os) throws IllegalArgumentException {
   for(Object o in os) checkNull(o);  
}

然后检查变成：

public void someFun(String val1, String val2) throws IllegalArgumentException {
   ExceptionUtilities.checkNull(val1, "val1");
   ExceptionUtilities.checkNull(val2, "val2");

   /** alternatively:
   ExceptionUtilities.checkNull(val1, val2);
   **/

   /** ... **/
} 

可以使用编辑器宏或代码处理脚本添加该内容 。
编辑：也可以通过这种方式添加详细检查，但我认为自动添加单行要容易得多。

Answer 15

使用断言和抛出异常都是有效的方法。 任一机制都可用于指示编程错误，而不是运行时错误，如此处的情况。

• 断言具有性能优势，因为它们通常在生产系统上被禁用。
• 异常具有安全性的优点，因为总是执行检查。

选择实际上取决于项目的开发实践。 整个项目需要决定断言策略：如果选择在所有开发过程中启用断言，那么我会说使用断言来检查这种无效参数 - 在生产系统中，由于以下原因抛出 NullPointerException无论如何，编程错误不太可能以有意义的方式被捕获和处理，因此就像断言一样。

但实际上，我知道很多开发人员不相信断言会在适当的时候启用，因此选择抛出 NullPointerException 来确保安全。

当然，如果您无法为您的代码强制执行策略（例如，如果您正在创建一个库，因此取决于其他开发人员运行您的代码的方式），您应该选择抛出 NullPointerException 的安全方法属于库 API 一部分的方法。

Answer 16

一般规则是，如果您的方法不需要 null 参数，那么您应该抛出 System.ArgumentNullException。 抛出正确的异常不仅可以保护您免受资源损坏和其他不良情况的影响，还可以为您的代码用户提供指导，从而节省调试代码的时间。

另请阅读有关防御性编程的文章