這篇文章主要講解了“Java中如何解決null值引起的Bug”，文中的講解內(nèi)容簡單清晰，易于學(xué)習(xí)與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“Java中如何解決null值引起的Bug”吧！

創(chuàng)新互聯(lián)是少有的網(wǎng)站建設(shè)、做網(wǎng)站、營銷型企業(yè)網(wǎng)站、小程序定制開發(fā)、手機APP,開發(fā)、制作、設(shè)計、賣友情鏈接、推廣優(yōu)化一站式服務(wù)網(wǎng)絡(luò)公司,2013年至今,堅持透明化,價格低,無套路經(jīng)營理念。讓網(wǎng)頁驚喜每一位訪客多年來深受用戶好評

業(yè)務(wù)中的空值

場景

存在一個 UserSearchService用來提供用戶查詢的功能： 

public interface UserSearchService{       List<User> listUser();       User get(Integer id);     }

問題現(xiàn)場

對于面向?qū)ο笳Z言來講，抽象層級特別的重要。尤其是對接口的抽象，它在設(shè)計和開發(fā)中占很大的比重，我們在開發(fā)時希望盡量面向接口編程。

對于以上描述的接口方法來看，大概可以推斷出可能它包含了以下兩個含義:

•  listUser(): 查詢用戶列表

•  get(Integerid): 查詢單個用戶

在所有的開發(fā)中，XP推崇的TDD模式可以很好的引導(dǎo)我們對接口的定義，所以我們將TDD作為開發(fā)代碼的”推動者”。

對于以上的接口，當(dāng)我們使用TDD進(jìn)行測試用例先行時，發(fā)現(xiàn)了潛在的問題：

•  listUser() 如果沒有數(shù)據(jù)，那它是返回空集合還是null呢？

•  get(Integerid) 如果沒有這個對象，是拋異常還是返回null呢？

深入listUser研究

我們先來討論 

listUser()

這個接口，經(jīng)?？吹饺缦聦崿F(xiàn)：

public List<User> listUser(){        List<User> userList = userListRepostity.selectByExample(new UserExample());        if(CollectionUtils.isEmpty(userList)){//spring util工具類          return null;        }        return userList;    }

這段代碼返回是null,從我多年的開發(fā)經(jīng)驗來講，對于集合這樣返回值，最好不要返回null，因為如果返回了null，會給調(diào)用者帶來很多麻煩。你將會把這種調(diào)用風(fēng)險交給調(diào)用者來控制。

如果調(diào)用者是一個謹(jǐn)慎的人，他會進(jìn)行是否為null的條件判斷。如果他并非謹(jǐn)慎，或者他是一個面向接口編程的狂熱分子(當(dāng)然，面向接口編程是正確的方向)，他會按照自己的理解去調(diào)用接口，而不進(jìn)行是否為null的條件判斷，如果這樣的話，是非常危險的，它很有可能出現(xiàn)空指針異常！

基于此，我們將它進(jìn)行優(yōu)化：

public List<User> listUser(){        List<User> userList = userListRepostity.selectByExample(new UserExample());        if(CollectionUtils.isEmpty(userList)){          return Lists.newArrayList(); //guava類庫提供的方式        }        return userList;    }

對于接口( ListlistUser())，它一定會返回List，即使沒有數(shù)據(jù)，它仍然會返回List（集合中沒有任何元素）;

通過以上的修改，我們成功的避免了有可能發(fā)生的空指針異常，這樣的寫法更安全！

深入研究get方法

對于接口

User get(Integer id)

你能看到的現(xiàn)象是，我給出id，它一定會給我返回User.但事實真的很有可能不是這樣的。

我看到過的實現(xiàn):

public User get(Integer id){      return userRepository.selectByPrimaryKey(id);//從數(shù)據(jù)庫中通過id直接獲取實體對象    }

相信很多人也都會這樣寫。

通過代碼的時候得知它的返回值很有可能是null! 但我們通過的接口是分辨不出來的!

這個是個非常危險的事情。尤其對于調(diào)用者來說！

我給出的建議是，需要在接口明明時補充文檔,比如對于異常的說明,使用注解@exception： 

public interface UserSearchService{        /**         * 根據(jù)用戶id獲取用戶信息         * @param id 用戶id         * @return 用戶實體         * @exception UserNotFoundException         */        User get(Integer id);      }

我們把接口定義加上了說明之后，調(diào)用者會看到，如果調(diào)用此接口，很有可能拋出“UserNotFoundException(找不到用戶)”這樣的異常。

這種方式可以在調(diào)用者調(diào)用接口的時候看到接口的定義，但是，這種方式是”弱提示”的！

如果調(diào)用者忽略了注釋，有可能就對業(yè)務(wù)系統(tǒng)產(chǎn)生了風(fēng)險，這個風(fēng)險有可能導(dǎo)致一個億！

除了以上這種”弱提示”的方式，還有一種方式是，返回值是有可能為空的。那要怎么辦呢？

我認(rèn)為我們需要增加一個接口，用來描述這種場景.

引入jdk8的Optional,或者使用guava的Optional.看如下定義: 

public interface UserSearchService{       /**        * 根據(jù)用戶id獲取用戶信息        * @param id 用戶id        * @return 用戶實體,此實體有可能是缺省值        */       Optional<User> getOptional(Integer id);     }

Optional有兩個含義: 存在 or 缺省。

那么通過閱讀接口getOptional()，我們可以很快的了解返回值的意圖，這個其實是我們想看到的，它去除了二義性。

它的實現(xiàn)可以寫成:

public Optional<User> getOptional(Integer id){    return Optional.ofNullable(userRepository.selectByPrimaryKey(id));  }

深入入?yún)?/strong>

通過上述的所有接口的描述，你能確定入?yún)d一定是必傳的嗎？我覺得答案應(yīng)該是：不能確定。除非接口的文檔注釋上加以說明。

那如何約束入?yún)⒛?

推薦兩種方式：

•  強制約束

•  文檔性約束（弱提示）

1.強制約束，我們可以通過jsr 303進(jìn)行嚴(yán)格的約束聲明： 

public interface UserSearchService{       /**        * 根據(jù)用戶id獲取用戶信息        * @param id 用戶id        * @return 用戶實體        * @exception UserNotFoundException        */       User get(@NotNull Integer id);       /**        * 根據(jù)用戶id獲取用戶信息        * @param id 用戶id        * @return 用戶實體,此實體有可能是缺省值        */       Optional<User> getOptional(@NotNull Integer id);     }

當(dāng)然，這樣寫，要配合AOP的操作進(jìn)行驗證，但讓spring已經(jīng)提供了很好的集成方案，在此就不在贅述了。

2.文檔性約束

在很多時候，我們會遇到遺留代碼，對于遺留代碼，整體性改造的可能性很小。

我們更希望通過閱讀接口的實現(xiàn)，來進(jìn)行接口的說明。

jsr 305規(guī)范，給了我們一個描述接口入?yún)⒌囊粋€方式(需要引入庫 com.google.code.findbugs:jsr305):

可以使用注解: @Nullable @Nonnull @CheckForNull 進(jìn)行接口說明。比如:

public interface UserSearchService{     /**      * 根據(jù)用戶id獲取用戶信息      * @param id 用戶id      * @return 用戶實體      * @exception UserNotFoundException      */     @CheckForNull     User get(@NonNull Integer id);     /**      * 根據(jù)用戶id獲取用戶信息      * @param id 用戶id      * @return 用戶實體,此實體有可能是缺省值      */     Optional<User> getOptional(@NonNull Integer id);   }

小結(jié)

通過 空集合返回值,Optional,jsr 303，jsr 305這幾種方式，可以讓我們的代碼可讀性更強，出錯率更低！

•  空集合返回值 ：如果有集合這樣返回值時，除非真的有說服自己的理由，否則，一定要返回空集合，而不是null

•  Optional: 如果你的代碼是jdk8，就引入它！如果不是，則使用Guava的Optional,或者升級jdk版本！它很大程度的能增加了接口的可讀性！

•  jsr 303: 如果新的項目正在開發(fā)，不防加上這個試試！一定有一種特別爽的感覺!

•  jsr 305: 如果老的項目在你的手上，你可以嘗試的加上這種文檔型注解，有助于你后期的重構(gòu)，或者新功能增加了，對于老接口的理解!

空對象模式

場景

來看一個DTO轉(zhuǎn)化的場景，對象: 

@Data     static class PersonDTO{       private String dtoName;       private String dtoAge;     }     @Data     static class Person{      private String name;       private String age;    }

需求是將Person對象轉(zhuǎn)化成PersonDTO，然后進(jìn)行返回。

當(dāng)然對于實際操作來講，返回如果Person為空，將返回null,但是PersonDTO是不能返回null的（尤其Rest接口返回的這種DTO）。

在這里，我們只關(guān)注轉(zhuǎn)化操作，看如下代碼:

@Test   public void shouldConvertDTO(){     PersonDTO personDTO = new PersonDTO();     Person person = new Person();     if(!Objects.isNull(person)){       personDTO.setDtoAge(person.getAge());       personDTO.setDtoName(person.getName());     }else{       personDTO.setDtoAge("");       personDTO.setDtoName("");     }   }

優(yōu)化修改

這樣的數(shù)據(jù)轉(zhuǎn)化，可讀性非常差，每個字段的判斷，如果是空就設(shè)置為空字符串(“”)

換一種思維方式進(jìn)行思考，我們是拿到Person這個類的數(shù)據(jù)，然后進(jìn)行賦值操作(setXXX),其實是不關(guān)系Person的具體實現(xiàn)是誰的。

那我們可以創(chuàng)建一個Person子類:

static class NullPerson extends Person{      @Override      public String getAge() {        return "";      }      @Override      public String getName() {        return "";      }    }

它作為Person的一種特例而存在，如果當(dāng)Person為空的時候，則返回一些 get*的默認(rèn)行為.

所以代碼可以修改為: 

@Test      public void shouldConvertDTO(){        PersonDTO personDTO = new PersonDTO();        Person person = getPerson();        personDTO.setDtoAge(person.getAge());        personDTO.setDtoName(person.getName());      }      private Person getPerson(){        return new NullPerson();   //如果Person是null ,則返回空對象     }

其中 getPerson()方法，可以用來根據(jù)業(yè)務(wù)邏輯獲取Person有可能的對象（對當(dāng)前例子來講，如果Person不存在，返回Person的的特例NUllPerson），如果修改成這樣，代碼的可讀性就會變的很強了。

使用Optional可以進(jìn)行優(yōu)化

空對象模式，它的弊端在于需要創(chuàng)建一個特例對象，但是如果特例的情況比較多，我們是不是需要創(chuàng)建多個特例對象呢，雖然我們也使用了面向?qū)ο蟮亩鄳B(tài)特性，但是，業(yè)務(wù)的復(fù)雜性如果真的讓我們創(chuàng)建多個特例對象，我們還是要再三考慮一下這種模式，它可能會帶來代碼的復(fù)雜性。

對于上述代碼，還可以使用Optional進(jìn)行優(yōu)化。 

@Test        public void shouldConvertDTO(){          PersonDTO personDTO = new PersonDTO();          Optional.ofNullable(getPerson()).ifPresent(person -> {            personDTO.setDtoAge(person.getAge());            personDTO.setDtoName(person.getName());          });        }        private Person getPerson(){          return null;        }

Optional對空值的使用，我覺得更為貼切，它只適用于”是否存在”的場景。

如果只對控制的存在判斷，我建議使用Optional。

Optioanl的正確使用

Optional如此強大，它表達(dá)了計算機最原始的特性(0 or 1),那它如何正確的被使用呢!

Optional不要作為參數(shù)

如果你寫了一個public方法，這個方法規(guī)定了一些輸入?yún)?shù)，這些參數(shù)中有一些是可以傳入null的，那這時候是否可以使用Optional呢？

給的建議是: 一定不要這樣使用!

舉個例子: 

public interface UserService{        List<User> listUser(Optional<String> username);      }

這個例子的方法 listUser,可能在告訴我們需要根據(jù)username查詢所有數(shù)據(jù)集合，如果username是空，也要返回所有的用戶集合.

當(dāng)我們看到這個方法的時候，會覺得有一些歧義:

“如果username是absent,是返回空集合嗎？還是返回全部的用戶數(shù)據(jù)集合？”

Optioanl是一種分支的判斷，那我們究竟是關(guān)注 Optional還是Optional.get()呢？

給大家的建議是，如果不想要這樣的歧義，就不要使用它！

如果你真的想表達(dá)兩個含義，就給它拆分出兩個接口:

public interface UserService{      List<User> listUser(String username);      List<User> listUser();    }

我覺得這樣的語義更強，并且更能滿足 軟件設(shè)計原則中的 “單一職責(zé)”。

如果你覺得你的入?yún)⒄娴挠斜匾赡軅鱪ull,那請使用jsr 303或者jsr 305進(jìn)行說明和驗證!

請記住! Optional不能作為入?yún)⒌膮?shù)!

Optional作為返回值

當(dāng)個實體的返回

那Optioanl可以做為返回值嗎？

其實它是非常滿足是否存在這個語義的。

你如說，你要根據(jù)id獲取用戶信息，這個用戶有可能存在或者不存在。

你可以這樣使用:

public interface UserService{     Optional<User> get(Integer id);   }

當(dāng)調(diào)用這個方法的時候，調(diào)用者很清楚get方法返回的數(shù)據(jù)，有可能不存在，這樣可以做一些更合理的判斷，更好的防止空指針的錯誤！

當(dāng)然，如果業(yè)務(wù)方真的需要根據(jù)id必須查詢出User的話，就不要這樣使用了，請說明，你要拋出的異常.

只有當(dāng)考慮它返回null是合理的情況下，才進(jìn)行Optional的返回

集合實體的返回

不是所有的返回值都可以這樣用的！如果你返回的是集合：

public interface UserService{    Optional<List<User>> listUser();  }

這樣的返回結(jié)果，會讓調(diào)用者不知所措，是否我判斷Optional之后，還用進(jìn)行isEmpty的判斷呢？

這樣帶來的返回值歧義！我認(rèn)為是沒有必要的。

我們要約定，對于List這種集合返回值，如果集合真的是null的，請返回空集合(Lists.newArrayList);

使用Optional變量 

Optional<User> userOpt = ...

如果有這樣的變量userOpt,請記住 ：

•  一定不能直接使用get ，如果這樣用，就喪失了Optional本身的含義 （ 比如userOp.get() ）

•  不要直接使用getOrThrow ,如果你有這樣的需求：獲取不到就拋異常。那就要考慮，是否是調(diào)用的接口設(shè)計的是否合理

getter中的使用

對于一個java bean,所有的屬性都有可能返回null,那是否需要改寫所有的getter成為Optional類型呢？

給大家的建議是，不要這樣濫用Optional.

即便 我java bean中的getter是符合Optional的，但是因為java bean 太多了，這樣會導(dǎo)致你的代碼有50%以上進(jìn)行Optinal的判斷，這樣便污染了代碼。(我想說，其實你的實體中的字段應(yīng)該都是由業(yè)務(wù)含義的，會認(rèn)真的思考過它存在的價值的，不能因為Optional的存在而濫用)

我們應(yīng)該更關(guān)注于業(yè)務(wù)，而不只是空值的判斷。

不要在getter中濫用Optional.

感謝各位的閱讀，以上就是“Java中如何解決null值引起的Bug”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對Java中如何解決null值引起的Bug這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是創(chuàng)新互聯(lián)，小編將為大家推送更多相關(guān)知識點的文章，歡迎關(guān)注！