先举个例子
public Result doSomething(String balabala);
public class Result{
private Long productId;
....
}
上面接口是其他部门的程序员提供给你的。没有文档,接口没有注释。
首先,我调用这个接口,
Result result= doSomething("fuck");
调用之后,我要返回的productId再去请求其他接口,做其他一些事情。
问题来了:
对这个返回的result,你是直接result.getProductId(); 还是先判断一下,result!= null 然后再result.getProductId();那productId又是Result里的引用类型,你拿到productId要不要再productId != null
,Result还有其他的引用类型,是不是我每用一个非得判空?
可能每个人的习惯不一样,比如写那个接口,有的人是哪怕什么信息都没有返回,也返回一个空的result。有的人是如果没有信息返回就返回null。如果只要是引用类型,我都判断是否为空,是不是显得“过于谨慎”了。文档,注释也不可能规定的那么细,程序员之间的约定吧,那一个几百人的团队,难免会有不遵循约定的。你们是如何处理的?
又比如一条记录,业务上规定,productId不可能为空的,但是这条记录的插入涉及到两条sql语句,一个程序员的失误没有保证原子性,导致productId为空的记录被插入进去了。这时候,我一旦涉及到处理productId,没有判空,则很有可能导致异常
伊谢尔伦2017-04-18 09:56:07
我觉得这个问题,首先在接口的定义。
如果接口有明确的定义说明不会返回 null,那么就不需处理 null 返回值的情况。反之,则需要处理。
如果出现问题,就可以向对方提出 bug,要求对方予以修复。
如果没有明确的定义,或者接口提供方不是本公司的,或者对方有问题不能及时改正,那就只能自己这边做一些防御性的代码了。而且可以在自己这边通过对接口进行包装的方式来保证不会返回 null。
怪我咯2017-04-18 09:56:07
对接口的定义就要说清楚什么时候返回null,返回null是什么意思。
如果没说清楚让对方说清楚。说清楚了照着做就是了。如果照着做了还出问题那一般就是对方的问题了,让对方改。