将null传递给方法 [英] Passing null to a method

查看:172
本文介绍了将null传递给方法的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在阅读优秀的清洁代码



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

  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){
抛出新的IllegalArgumentException(无效xProjection的参数);
}
return(p2.x - p1.x)* 1.5;
}

public double xProjection(Point p1,Point p2){
assert p1!= null:p1不应为null;
断言p2!= null:p2不应该为空;
return(p2.x - p1.x)* 1.5;
}

我更喜欢断言方法,但我不喜欢断言默认关闭的事实。



本书最后说明:


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


它实际上并不是你会怎么做强制执行此限制?



你们中是否有任何一方都有强烈意见。

解决方案

断言的使用和抛出异常都是有效的方法。这两种机制都可以用来表示编程错误,而不是运行时错误,就像这里的情况一样。




  • 断言具有性能优势因为它们通常在生产系统上被禁用。

  • 例外情况具有安全性,因为始终执行检查。



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



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



当然,如果你不能执行一个策略你的代码(例如,如果你正在创建一个库,因此依赖于其他开发人员如何运行你的代码),你应该选择为那些属于库API的方法抛出NullPointerException的安全方法。 p>

I am in the middle of reading the excellent Clean Code

One discussion is regarding passing nulls into a method.

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

It represents different ways of handling this:

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

I prefer the assertions approach, but I don't like the fact that assertions are turned off by default.

The book finally states:

In most programming languages there is no good way to deal with a null that is passed by a caller accidentally. Because this is the case, the rational approach is to forbid passing null by default.

It doesn't really go into how you would enforce this restriction?

Do any of you have strong opinions either way.

解决方案

Both the use of assertions and the throwing of exceptions are valid approaches here. Either mechanism can be used to indicate a programming error, not a runtime error, as is the case here.

  • Assertions have the advantage of performance as they are typically disabled on production systems.
  • Exceptions have the advantage of safety, as the check is always performed.

The choice really depends on the development practices of the project. The project as a whole needs to decide on an assertion policy: if the choice is to enable assertions during all development, then I'd say to use assertions to check this kind of invalid parameter - in a production system, a NullPointerException thrown due to a programming error is unlikely to be able to be caught and handled in a meaningful way anyway and so will act just like an assertion.

Practically though, I know a lot of developers that don't trust that assertions will be enabled when appropriate and so opt for the safety of throwing a NullPointerException.

Of course if you can't enforce a policy for your code (if you're creating a library, for example, and so are dependent on how other developers run your code), you should opt for the safe approach of throwing NullPointerException for those methods that are part of the library's API.

这篇关于将null传递给方法的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆