我们该信任接口的返回值吗？

Question

先举个例子

public Result doSomething(String balabala);


public class Result{
    private Long productId;
    ....
}

上面接口是其他部门的程序员提供给你的。没有文档，接口没有注释。
首先，我调用这个接口，

Result result= doSomething("fuck");

调用之后，我要返回的productId再去请求其他接口，做其他一些事情。

问题来了：

1. 对这个返回的result，你是直接result.getProductId(); 还是先判断一下，result！= null 然后再result.getProductId()；那productId又是Result里的引用类型，你拿到productId要不要再productId ！= null
   ，Result还有其他的引用类型，是不是我每用一个非得判空？

可能每个人的习惯不一样，比如写那个接口，有的人是哪怕什么信息都没有返回，也返回一个空的result。有的人是如果没有信息返回就返回null。如果只要是引用类型，我都判断是否为空，是不是显得“过于谨慎”了。文档，注释也不可能规定的那么细，程序员之间的约定吧，那一个几百人的团队，难免会有不遵循约定的。你们是如何处理的？

又比如一条记录，业务上规定，productId不可能为空的，但是这条记录的插入涉及到两条sql语句，一个程序员的失误没有保证原子性，导致productId为空的记录被插入进去了。这时候，我一旦涉及到处理productId，没有判空，则很有可能导致异常

Answer 1

不相信，有问题抛异常，异常指明是调用xx接口xx原因引发，这样有问题也找不到你。。。

Answer 2

其实你已经知道答案了，只是你觉得这样写代码太累了，想有人告诉你一句“不需要”而已。

然而，事实你也是清楚的。

跟这个问题有点相似的就是：永远不要相信前端传过来的数据。
同样，如果公司内部毫无规范可言且大家水平参差的话，这种不信任的感觉更甚。最终写出来的代码，可能写一行业务代码就要若干层防御性代码包围着。这样项目的维护成本会越来越高。
如果这个问题的发生频率很高，那应该抛给上一级领导去从上层层面解决这个问题。

个人意见：
在Result里面添加一个errorCode的字段，然后取数据的人就根据这个值判断该返回结果是否合法。

前提条件：
1、errorCode=0是合法，其余非法；

假设：
1、返回的Result是null：这种情况个人认为属于warning级别（但听说大部分程序员都忽略warning？），遇到这种情况建议跟接口提供方提出问题，建议对方规范返回值；
2、返回的Result不为null，且errorCode=0，但productId依然为null：这种情况已经属于error级别了，需要跟对方严正交涉了，这种时候：
a) 如果你有跟对方开撕的底气，直接开撕；
b) 如果a不行，那就向上级反映问题，让上级去帮忙解决该问题；
c) 如果b不行，能忍就干下去，不能忍就走。

Answer 3

学车的时候，教练说过一句话，“永远不要相信别人的开车技术”，同理，永远不要相信别的猪队友能写出严谨的代码，除非你们互相约定，并且邮件确认，否则你就要判断各种情况。

Answer 4

哎,正是这种原因造成代码冗余,还是事先商量好最好

Answer 5

1. 根据业务场景来确定,如果接口的含义是「通过skuId获取商品详情」.在这个业务场景下,对于服务提供者来说,当我们传入一个系统不存在的skuId,接口返回给我们一个null是合理的,所以这里需要对Result进行判空

2. Result里面的productId是否需要判空,需要向接口服务提供者进行咨询(productId是否为空),个人建议对外暴露的接口,返回的实体里面出现的字段,必须要保证值是有意义的(比如说productId在业务上必须不为空,那么如果接口返回的实体里面包含了这个字段,这个字段肯定是不为空的)

3. 楼主说的如果程序员事务没有保证原子性,需要分两部分来解决.前提productId在业务上一定不可能为空,如果出现了问题,为了快速修复线上BUG,允许上一个紧急的版本,进行判空处理.正常情况下不需要判空,让错误尽快的暴露出来

4. 如果这个服务对你来说是一个弱依赖服务,建议对这种不稳定的接口必须的时候进行降级处理,这样就算服务提供方接口写的不规范,也不会影响自己本身的流程

Answer 6

因为很多人都喜欢打破规矩，不按规矩办事，所以会认为接口是不被信任的。

但是，接口就是规则，定义接口的目的就是要实现的类按规则办事，所以，首先应该采取信任的态度。

当然，任何人任何程序都有可能出错，如果确实接口实现出错了，应该向实现方提出 BUG 报告，在等等对方修改之前，可以先用自己的代码的规避错误。然而，这是一种临时解决方案，应该通过注释注明，待接口实现方修改 BUG 之后去掉这部分临时代码（不排除永远也去不掉的可能，但注释会给后来人说明原因）。

总的来说，遵循规则，以信任为主。但不排除部分接口实现错误的情况，需要临时代码处理掉。

补充一下：没有文档的接口，也就是规则不明。规则不明那就只能考虑所有情况——相当于不信任。

Answer 7

建议还是判断下吧。 独立到一个私有方法内。

Answer 8

程序都是有上下文的，接口也是有规范的。在实现某个功能之前大家已经做了相关约定，那就应该照规范执行，而不是盲目的写上些防止NullPointerException的代码。

Answer 9

**既然你们对返回的接口封装了一个类Result ，那么你们可以写一个公共的工具类，来对Result来做检查。**

Answer 10

JDK8或者Guava的Optional能够起到一点小帮助

Answer 11

用kotlin去写。

Answer 12

我觉得这个问题，首先在接口的定义。

如果接口有明确的定义说明不会返回 null，那么就不需处理 null 返回值的情况。反之，则需要处理。
如果出现问题，就可以向对方提出 bug，要求对方予以修复。

如果没有明确的定义，或者接口提供方不是本公司的，或者对方有问题不能及时改正，那就只能自己这边做一些防御性的代码了。而且可以在自己这边通过对接口进行包装的方式来保证不会返回 null。

Answer 13

我只看了标题就能很明确的说,不能相信,即使前期你们接口定义如何规范,如何透明,相信我如果不做容错处理,不做异常处理,最后哭的还是自己~~

Answer 14

既然是接口，那就要接口提供者提供明确的参数和返回值的说明，这是提供接口方的常识。如果这都做不到，你应该知道该怎么做。

Answer 15

对接口的定义就要说清楚什么时候返回null，返回null是什么意思。

如果没说清楚让对方说清楚。说清楚了照着做就是了。如果照着做了还出问题那一般就是对方的问题了，让对方改。