先举个例子
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，没有判空，则很有可能导致异常
用kotlin去寫。
我覺得這個問題，首先在介面的定義。
如果介面有明確的定義說明不會傳回 null，那麼就不需要處理 null 回傳值的情況。反之，則需要處理。
如果有問題，就可以向對方提出 bug，請對方修復。
如果沒有明確的定義，或者介面提供者不是本公司的，或者對方有問題不能及時改正，那就只能自己這邊做一些防禦性的代碼了。而且可以在自己這邊透過對介面進行包裝的方式來保證不會回傳 null。
我只看了標題就能很明確的說,不能相信,即使前期你們接口定義如何規範,如何透明,相信我如果不做容錯處理,不做異常處理,最後哭的還是自己~~
既然是接口，那就要接口提供者提供明確的參數和返回值的說明，這是提供接口方的常識。如果這都做不到，你應該知道該怎麼做。
對介面的定義就要說清楚什麼時候回傳null，回傳null是什麼意思。
如果沒說清楚讓對方說清楚。說清楚了照著做就是了。如果照著做了還出問題那一般就是對方的問題了，讓對方改。