先举个例子
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，没有判空，则很有可能导致异常
不相信，有問題拋異常，異常指明是呼叫xx介面xx原因引發，這樣有問題也找不到你。 。 。
其實你已經知道答案了，只是你覺得這樣寫程式太累了，想有人告訴你一句「不需要」而已。
然而，事實你也是清楚的。
跟這個問題有點相似的就是：永遠不要相信前端傳過來的數據。
同樣，如果公司內部毫無規範可言且大家水平參差的話，這種不信任的感覺更甚。最後寫出來的程式碼，可能寫一行業務程式碼就要若干層防禦性程式碼包圍著。這樣專案的維護成本會越來越高。
如果這個問題的發生頻率很高，那應該拋給上一級領導去從上層層級解決這個問題。
個人意見：
在
Result里面添加一个errorCode的字段，然後取資料的人就根據這個值判斷該返回結果是否合法。前提條件：
1、
errorCode=0是合法，其餘非法；假設：
1、回傳的
Result是null：這種情況個人認為屬於warning等級（但聽說大部分程序員都忽略warning？ >null，且Result是null：这种情况个人认为属于warning级别（但听说大部分程序员都忽略warning？），遇到这种情况建议跟接口提供方提出问题，建议对方规范返回值；2、返回的
Result不为null，且errorCode=0，但productId依然为null：这种情况已经属于error，但productId還是null：這種情況已經屬於error等級了，需要跟對方嚴正交涉了，這種時候：a) 如果你有跟對方開撕的底氣，直接開撕；
b) 如果a不行，那就向上級反映問題，讓上級去幫忙解決該問題；
c) 如果b不行，能忍就乾下去，不能忍就走。
學車的時候，教練說過一句話，“永遠不要相信別人的開車技術”，同理，永遠不要相信別的豬隊友能寫出嚴謹的代碼，除非你們互相約定，並且郵件確認，否則你就要判斷各種情況。
哎,正是這種原因造成代碼冗餘,還是事先商量好最好
根據業務場景來確定,如果介面的含義是「透過
skuId获取商品详情」.在这个业务场景下,对于服务提供者来说,当我们传入一个系统不存在的skuId,接口返回给我们一个null是合理的,所以这里需要对Result進行判空Result里面的productId是否需要判空,需要向接口服务提供者进行咨询(productId是否为空),个人建议对外暴露的接口,返回的实体里面出现的字段,必须要保证值是有意义的(比如说productId在業務上必須不為空,那麼如果介面返回的實體裡麵包含了這個字段,這個字段肯定是不為空的)樓主說的如果程式設計師事務沒有保證原子性,需要分兩部分來解決.前提
productId在业务上一定不可能为空,如果出现了问题,为了快速修复线上BUG,允許上一個緊急的版本,進行判空處理.正常情況下不需要判空,讓錯誤盡快的暴露出來如果這個服務對你來說是一個弱依賴服務,建議對這種不穩定的接口必須的時候進行降級處理,這樣就算服務提供方接口寫的不規範,也不會影響自己本身的流程
因為很多人都喜歡打破規矩，不按規矩辦事，所以會認為介面是不被信任的。
但是，介面就是規則，定義介面的目的就是要實現的類別依規則辦事，所以，首先應該採取信任的態度。
當然，任何人任何程式都有可能出錯，如果確實介面實作出錯了，應該向實作方提出 BUG 報告，在等等對方修改之前，可以先用自己的程式碼的規避錯誤。然而，這是一種臨時解決方案，應該透過註解註明，待介面實作方修改 BUG 之後去掉這部分臨時程式碼（不排除永遠去不掉的可能，但註解會給後來人說明原因）。
總的來說，遵循規則，以信任為主。但不排除部分介面實作錯誤的情況，需要臨時程式碼處理掉。
補充一下：沒有文檔的接口，也就是規則不明。規則不明那隻能考慮所有情況──相當於不信任。
建議還是判斷下吧。 獨立到一個私有方法內。
程式都是有上下文的，介面也是有規範的。在實現某個功能之前大家已經做了相關約定，那就應該照規範執行，而不是盲目的寫上些防止
NullPointerException的程式碼。雷雷
JDK8或者Guava的Optional能夠起到一點小幫助