Heim > Fragen und Antworten > Hauptteil
先举个例子
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
其实你已经知道答案了,只是你觉得这样写代码太累了,想有人告诉你一句“不需要”而已。
然而,事实你也是清楚的。
跟这个问题有点相似的就是:永远不要相信前端传过来的数据。
同样,如果公司内部毫无规范可言且大家水平参差的话,这种不信任的感觉更甚。最终写出来的代码,可能写一行业务代码就要若干层防御性代码包围着。这样项目的维护成本会越来越高。
如果这个问题的发生频率很高,那应该抛给上一级领导去从上层层面解决这个问题。
个人意见:
在Result
里面添加一个errorCode
的字段,然后取数据的人就根据这个值判断该返回结果是否合法。
前提条件:
1、errorCode=0
是合法,其余非法;
假设:
1、返回的Result
是null
:这种情况个人认为属于warning
级别(但听说大部分程序员都忽略warning
?),遇到这种情况建议跟接口提供方提出问题,建议对方规范返回值;
2、返回的Result
不为null
,且errorCode=0
,但productId
依然为null:这种情况已经属于error
级别了,需要跟对方严正交涉了,这种时候:
a) 如果你有跟对方开撕的底气,直接开撕;
b) 如果a不行,那就向上级反映问题,让上级去帮忙解决该问题;
c) 如果b不行,能忍就干下去,不能忍就走。
怪我咯2017-04-18 09:56:07
学车的时候,教练说过一句话,“永远不要相信别人的开车技术”,同理,永远不要相信别的猪队友能写出严谨的代码,除非你们互相约定,并且邮件确认,否则你就要判断各种情况。
大家讲道理2017-04-18 09:56:07
根据业务场景来确定,如果接口的含义是「通过skuId
获取商品详情」.在这个业务场景下,对于服务提供者来说,当我们传入一个系统不存在的skuId
,接口返回给我们一个null
是合理的,所以这里需要对Result
进行判空
Result
里面的productId
是否需要判空,需要向接口服务提供者进行咨询(productId
是否为空),个人建议对外暴露的接口,返回的实体里面出现的字段,必须要保证值是有意义的(比如说productId
在业务上必须不为空,那么如果接口返回的实体里面包含了这个字段,这个字段肯定是不为空的)
楼主说的如果程序员事务没有保证原子性,需要分两部分来解决.前提productId
在业务上一定不可能为空,如果出现了问题,为了快速修复线上BUG
,允许上一个紧急的版本,进行判空处理.正常情况下不需要判空,让错误尽快的暴露出来
如果这个服务对你来说是一个弱依赖服务,建议对这种不稳定的接口必须的时候进行降级处理,这样就算服务提供方接口写的不规范,也不会影响自己本身的流程
PHP中文网2017-04-18 09:56:07
因为很多人都喜欢打破规矩,不按规矩办事,所以会认为接口是不被信任的。
但是,接口就是规则,定义接口的目的就是要实现的类按规则办事,所以,首先应该采取信任的态度。
当然,任何人任何程序都有可能出错,如果确实接口实现出错了,应该向实现方提出 BUG 报告,在等等对方修改之前,可以先用自己的代码的规避错误。然而,这是一种临时解决方案,应该通过注释注明,待接口实现方修改 BUG 之后去掉这部分临时代码(不排除永远也去不掉的可能,但注释会给后来人说明原因)。
总的来说,遵循规则,以信任为主。但不排除部分接口实现错误的情况,需要临时代码处理掉。
补充一下:没有文档的接口,也就是规则不明。规则不明那就只能考虑所有情况——相当于不信任。
迷茫2017-04-18 09:56:07
程序都是有上下文的,接口也是有规范的。在实现某个功能之前大家已经做了相关约定,那就应该照规范执行,而不是盲目的写上些防止NullPointerException
的代码。