如何優雅地根治null值引起的Bug？！

常聽到群里開發兄弟抱怨，實操時經常看到項目中存在到處空值判斷的情況，這些判斷，會讓人覺得摸不著頭緒，它的出現很有可能和當前的業務邏輯并沒有關系。但著實頭疼。。。 有時候，更可怕的是系統因為這些空值的情況，會拋出空指針異常，導致業務系統發生問題。本文總結了幾種關于空值的處理手法，分享給大家。 **業務中的空值** 場景 存在一個 UserSearchService用來提供用戶查詢的功能： **問題現場** 對于面向對象語言來講，抽象層級特別的重要。尤其是對接口的抽象，它在設計和開發中占很大的比重，我們在開發時希望盡量面向接口編程。 對于以上描述的接口方法來看，大概可以推斷出可能它包含了以下兩個含義: - listUser(): 查詢用戶列表 - get(Integerid): 查詢單個用戶 在所有的開發中，XP推崇的TDD模式可以很好的引導我們對接口的定義，所以我們將TDD作為開發代碼的”推動者”。 對于以上的接口，當我們使用TDD進行測試用例先行時，發現了潛在的問題： - listUser() 如果沒有數據，那它是返回空集合還是null呢？ - get(Integerid) 如果沒有這個對象，是拋異常還是返回null呢？ **深入listUser研究** 我們先來討論 這段代碼返回是null,從我多年的開發經驗來講，對于集合這樣返回值，最好不要返回null，因為如果返回了null，會給調用者帶來很多麻煩。你將會把這種調用風險交給調用者來控制。 如果調用者是一個謹慎的人，他會進行是否為null的條件判斷。如果他并非謹慎，或者他是一個面向接口編程的狂熱分子(當然，面向接口編程是正確的方向)，他會按照自己的理解去調用接口，而不進行是否為null的條件判斷，如果這樣的話，是非常危險的，它很有可能出現空指針異常！ 基于此，我們將它進行優化： 對于接口( ListlistUser())，它一定會返回List，即使沒有數據，它仍然會返回List（集合中沒有任何元素）; 通過以上的修改，我們成功的避免了有可能發生的空指針異常，這樣的寫法更安全！ **深入研究get方法** 對于接口 我們把接口定義加上了說明之后，調用者會看到，如果調用此接口，很有可能拋出“UserNotFoundException(找不到用戶)”這樣的異常。 這種方式可以在調用者調用接口的時候看到接口的定義，但是，這種方式是”弱提示”的！關注微信公眾號：互聯網架構師，在后臺回復：2T，可以獲取我整理的教程，都是干貨。 如果調用者忽略了注釋，有可能就對業務系統產生了風險，這個風險有可能導致一個億！ 除了以上這種”弱提示”的方式，還有一種方式是，返回值是有可能為空的。那要怎么辦呢？ 我認為我們需要增加一個接口，用來描述這種場景. 引入jdk8的Optional,或者使用guava的Optional.看如下定義: **深入入參** 通過上述的所有接口的描述，你能確定入參id一定是必傳的嗎？我覺得答案應該是：不能確定。除非接口的文檔注釋上加以說明。 那如何約束入參呢? 推薦兩種方式： - 強制約束 - 文檔性約束（弱提示） 1.強制約束，我們可以通過jsr 303進行嚴格的約束聲明： 當然，這樣寫，要配合AOP的操作進行驗證，但讓spring已經提供了很好的集成方案，在此就不在贅述了。 2.文檔性約束 在很多時候，我們會遇到遺留代碼，對于遺留代碼，整體性改造的可能性很小。 我們更希望通過閱讀接口的實現，來進行接口的說明。 jsr 305規范，給了我們一個描述接口入參的一個方式(需要引入庫 com.google.code.findbugs:jsr305): 可以使用注解: @Nullable @Nonnull @CheckForNull 進行接口說明。比如: **小結** 通過 空集合返回值,Optional,jsr 303，jsr 305這幾種方式，可以讓我們的代碼可讀性更強，出錯率更低！ 空集合返回值 ：如果有集合這樣返回值時，除非真的有說服自己的理由，否則，一定要返回空集合，而不是null Optional: 如果你的代碼是jdk8，就引入它！如果不是，則使用Guava的Optional,或者升級jdk版本！它很大程度的能增加了接口的可讀性！ jsr 303: 如果新的項目正在開發，不防加上這個試試！一定有一種特別爽的感覺! jsr 305: 如果老的項目在你的手上，你可以嘗試的加上這種文檔型注解，有助于你后期的重構，或者新功能增加了，對于老接口的理解! **空對象模式** 場景 來看一個DTO轉化的場景，對象: 優化修改 這樣的數據轉化，可讀性非常差，每個字段的判斷，如果是空就設置為空字符串(“”) 換一種思維方式進行思考，我們是拿到Person這個類的數據，然后進行賦值操作(setXXX),其實是不關系Person的具體實現是誰的。 那我們可以創建一個Person子類: 其中 getPerson()方法，可以用來根據業務邏輯獲取Person有可能的對象（對當前例子來講，如果Person不存在，返回Person的的特例NUllPerson），如果修改成這樣，代碼的可讀性就會變的很強了。 **使用Optional可以進行優化** 空對象模式，它的弊端在于需要創建一個特例對象，但是如果特例的情況比較多，我們是不是需要創建多個特例對象呢，雖然我們也使用了面向對象的多態特性，但是，業務的復雜性如果真的讓我們創建多個特例對象，我們還是要再三考慮一下這種模式，它可能會帶來代碼的復雜性。 對于上述代碼，還可以使用Optional進行優化。 Optional對空值的使用，我覺得更為貼切，它只適用于”是否存在”的場景。 如果只對控制的存在判斷，我建議使用Optional。 Optioanl的正確使用 Optional如此強大，它表達了計算機最原始的特性(0 or 1),那它如何正確的被使用呢! Optional不要作為參數 如果你寫了一個public方法，這個方法規定了一些輸入參數，這些參數中有一些是可以傳入null的，那這時候是否可以使用Optional呢？ 給的建議是: 一定不要這樣使用! 舉個例子: 我覺得這樣的語義更強，并且更能滿足 軟件設計原則中的 “單一職責”。 如果你覺得你的入參真的有必要可能傳null,那請使用jsr 303或者jsr 305進行說明和驗證! 請記住! Optional不能作為入參的參數! **Optional作為返回值** 當個實體的返回 那Optioanl可以做為返回值嗎？ 其實它是非常滿足是否存在這個語義的。 你如說，你要根據id獲取用戶信息，這個用戶有可能存在或者不存在。 你可以這樣使用: 這樣的返回結果，會讓調用者不知所措，是否我判斷Optional之后，還用進行isEmpty的判斷呢？ 這樣帶來的返回值歧義！我認為是沒有必要的。 我們要約定，對于List這種集合返回值，如果集合真的是null的，請返回空集合(Lists.newArrayList); **使用Optional變量** 如果有這樣的變量userOpt,請記住 ： - 一定不能直接使用get ，如果這樣用，就喪失了Optional本身的含義 （ 比如userOp.get() ） - 不要直接使用getOrThrow ,如果你有這樣的需求：獲取不到就拋異常。那就要考慮，是否是調用的接口設計的是否合理 **getter中的使用** 對于一個java bean,所有的屬性都有可能返回null,那是否需要改寫所有的getter成為Optional類型呢？ 給大家的建議是，不要這樣濫用Optional. 即便 我java bean中的getter是符合Optional的，但是因為java bean 太多了，這樣會導致你的代碼有50%以上進行Optinal的判斷，這樣便污染了代碼。(我想說，其實你的實體中的字段應該都是由業務含義的，會認真的思考過它存在的價值的，不能因為Optional的存在而濫用) 我們應該更關注于業務，而不只是空值的判斷。 不要在getter中濫用Optional. **小結** 可以這樣總結Optional的使用： - 當使用值為空的情況，并非源于錯誤時，可以使用Optional! - Optional不要用于集合操作! - 不要濫用Optional,比如在java bean的getter中! >【云棲號在線課堂】每天都有產品技術專家分享！ > 課程地址：https://yqh.aliyun.com/zhibo > 立即加入社群，與專家面對面，及時了解課程最新動態！ > 【云棲號在線課堂 社群】https://c.tb.cn/F3.Z8gvnK 原文發布時間：2020-07-09 本文作者：互聯網架構師 本文來自：“(https://mp.weixin.qq.com/s/6dQqX6RXt4nkmoEqp4_eKg)”，了解相關信息可以關注“(https://mp.weixin.qq.com/s/6dQqX6RXt4nkmoEqp4_eKg)”