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

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

I don’t believe it. If there is a problem, an exception will be thrown. The exception indicates that it is caused by calling xx interface xx. In this way, if there is a problem, you will not be found. . .

Answer 2

In fact, you already know the answer, but you feel that writing code like this is too tiring, and you want someone to tell you "no need".

However, you also know the facts.

Somewhat similar to this problem is: never trust the data transmitted from the front end.
Similarly, if there are no norms within the company and everyone has different levels of skills, this feeling of distrust will be even greater. The final code written may be surrounded by several layers of defensive code to write a line of business code. The maintenance cost of this project will become higher and higher.
If this problem occurs frequently, it should be left to the higher-level leadership to solve the problem from the upper level.

Personal opinion:
In the Result里面添加一个errorCode field, the person who retrieves the data will judge whether the returned result is legal based on this value.

Prerequisites:
1. errorCode=0 is legal, the rest are illegal;

Assumptions:
1. The returned Result is null: I personally think this situation belongs to the warning level (but I heard that most programs Members ignore warning?). When encountering this situation, it is recommended to raise questions with the interface provider and suggest that the other party standardize the return value; Result是null：这种情况个人认为属于warning级别（但听说大部分程序员都忽略warning？），遇到这种情况建议跟接口提供方提出问题，建议对方规范返回值；
2、返回的Result不为null，且errorCode=0，但productId依然为null：这种情况已经属于error2. The returned Result is not null, and
, but productId is still null: This situation already belongs to the error level, and you need to negotiate seriously with the other party. In this case:
a) If you have the confidence to argue with the other party, just do it;
b) If a doesn’t work, report the problem to your superiors and ask them to help solve the problem;

c) If b doesn’t work, do it if you can bear it. Go down and leave if you can't bear it anymore. 🎜

Answer 3

When I was learning to drive, the coach said, "Never trust other people's driving skills." In the same way, never trust other pig teammates to write rigorous code. Unless you mutually agree and confirm by email, otherwise you will To judge various situations.

Answer 4

Hey, it is this reason that causes code redundancy, it is best to discuss it in advance

Answer 5

1. Determine according to the business scenario, if the meaning of the interface is "empty judgment through skuId获取商品详情」.在这个业务场景下,对于服务提供者来说,当我们传入一个系统不存在的skuId,接口返回给我们一个null是合理的,所以这里需要对Result

2. Result里面的productId是否需要判空,需要向接口服务提供者进行咨询(productId是否为空),个人建议对外暴露的接口,返回的实体里面出现的字段,必须要保证值是有意义的(比如说productIdmust not be empty in business, then if the entity returned by the interface contains this field, this field must not be empty)

3. The poster said that if the programmer's transaction does not guarantee atomicity, it needs to be solved in two parts. The premise productId在业务上一定不可能为空,如果出现了问题,为了快速修复线上BUG is to allow the last emergency version to be nullified. Under normal circumstances, null judgment is not needed, so that errors can be exposed as soon as possible.

4. If this service is a weakly dependent service for you, it is recommended to downgrade this unstable interface when necessary, so that even if the service provider interface is not written in a standardized way, it will not affect your own process

Answer 6

Because many people like to break the rules and do things not according to the rules, they think that interfaces are not trusted.

However, interfaces are rules. The purpose of defining an interface is to make the implemented class act according to the rules. Therefore, you should first adopt an attitude of trust.

Of course, anyone and any program may make mistakes. If there is indeed an error in the interface implementation, you should submit a BUG report to the implementing party. Before waiting for the other party to modify it, you can use your own code to avoid the error. However, this is a temporary solution and should be noted through comments. This part of the temporary code will be removed after the interface implementer corrects the BUG (it does not rule out the possibility that it will never be removed, but the comments will explain the reason to future generations).

In general, follow the rules and focus on trust. However, it is not ruled out that some interface implementation errors may require temporary code to handle them.

To add: There is no documented interface, which means the rules are unclear. If the rules are unclear, then all situations can only be considered - which amounts to distrust.

Answer 7

It is recommended to make a judgment. Separate into a private method.

Answer 8

Programs have context and interfaces are standardized. Everyone has made relevant agreements before implementing a certain function, so they should be implemented according to the specifications instead of blindly writing some code to prevent NullPointerException.

Answer 9

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

Answer 10

JDK8或者Guava的OptionalIt can be a little help