求解去掉null值判断的解决方法

0 0

求解去掉null值判断的解决方法3

//假设这个方法要取到list.get(0)的值进行计算
//那么 这段方法的开头必须是
public void mymethod(List<A> list){
If(list!=null&&list.size()>0){
A  a= list.get(0);
If(a!=null){
//进行相关的业务实现
}
}
}
//或者也可以
public void mymethod(List<A> list){
try{
A  a= list.get(0);
//进行相关的业务实现
}
catch(Exception e){
//异常处理，但是抛出一个异常 成本应该是比较高的。
}
}
//请问各位看官 有没有更好地办法，控制入口值，
使这个方法变成这样
Public void mymethod(List<A> list){
A  a= list.get(0);
//进行相关的业务实现
}
//像null这种判断  我相信各位在java开发中 调用别人的接口时  会经常将取出来的值进行必要的null值判断，或者是在接受参数的时候做null值判断

问题补充：

OpenMind 写道

如果别人的接口返回的对象可能是null、也可能抛出异常，但接口上一般有说明的。如果接口明确说明可能返回null，那肯定要加null判断。你这时去掉null判断，难道加一个catch 空指针的处理吗？

OpenMind 写道

jvm构造异常的开销是比较大的,应该不推荐catch方式。但是程序员参差不齐，未必会在注释里面写明返回参数的值是否可能为null.
我的意思是像面向切面编程一样，把null这种判断的工作简化，交由第三方来做。而不是我调用一次方法就要做繁琐的null值判断，感觉代码看起来很丑。

问题补充：

OpenMind 写道

面向切面的方法好像都是通过代理调用的吧，开销也比较大，为了省略一个null值判断而用切面编程，我觉得不可取，当然不判断null值而是catch空指针的做法更加是舍本逐末。

如果你的业务处理逻辑是一个过滤器链的结构，那么在其中一个节点加上一个通用的对null值判断的过滤器可以省下你所面临的麻烦。

我的纠结点是，每次调用别人提供的接口方法，就会对返回值进行null值判断，如果调用别人的接口比较多的话，这样一来，整段代码里面充斥着null判断的if语句，像我的话一般是if(xx==null)return;，不喜欢超过2层的if嵌套结构。
目前我也没想到很好的办法，我的一个考虑是，调用mymethod(list)方法的层，先对list进行判断，然后再传到mymethod(list)里面，这样的话mymethod方法内部就不用做判断。所有的null值最好在上层做掉，而在下层的应用里面，起码传递进来的参数不用做null值判断。这是这样做的话，就要求所有合作的程序员按照规范来，存在一定的风险，万一哪个家伙，在上层忘了做null判断传递到下层应用，那后果就比较惨了。。。
我现在的纠结点是：1 一定的代码冗余是必要的，会大大降低风险。
但是代码看起来很丑，并且效率会略低。
2如果去掉不必要的冗余，那就需要高素质的程序员配合。但是现实往往不可控。

问题补充：

hudepin 写道

就是第一种吧我一般都用的第一种，难道还要什么更好的处理方法

我目前没想到，也是用的第一种

问题补充：

aoxer 写道

对方法配置拦截器应该可以实现你想要的功能，不过对方法返回值的处理往往跟你的业务逻辑相关，而且编码人员必须有处理这种情况的意识，如果你把这些处理都屏蔽了，我觉得不是什么好事情。

你说的对，但是一用参数，就做null值判断，这点感觉有些不爽，也算是鄙人的一点编程洁癖吧。