将null传递给方法

工具包 :

我正在阅读优秀的Clean Code

一个讨论是关于将空值传递给方法。

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;
}

我更喜欢断言方法,但是我不喜欢断言默认情况下处于关闭状态的事实。

该书最后指出:

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

它实际上并没有涉及如何实施此限制?

无论哪种方式,您中的任何人都有强烈的意见。

罗素市长:

在这里,使用断言和引发异常都是有效的方法。任何一种机制都可以用来指示编程错误,而不是运行时错误,如此处的情况。

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

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

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

当然,如果您不能为代码强制执行策略(例如,如果您正在创建库,并且这取决于其他开发人员如何运行您的代码),则应该选择对那些代码抛出NullPointerException的安全方法库API的一部分的方法。

本文收集自互联网,转载请注明来源。

如有侵权,请联系 [email protected] 删除。

编辑于
0

我来说两句

0 条评论
登录 后参与评论

相关文章