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