NullPointException應該算是每一個碼農(nóng)都很熟悉的家伙了吧？誰的代碼不曾拋過幾個空指針異常呢…

比如：你寫了段如下的代碼：

public void getCompanyFromEmployee() { Employee employee = getEmployee(); Company company = employee.getTeam().getDepartment().getCompany(); System.out.println(company);}private Employee getEmployee() { Employee employee = new Employee(); employee.setEmployeeName(“JiaGouWuDao”); employee.setTeam(new Team(“DevTeam4”)); return employee;}

運行程序，你可能就等不到你需要的結果，而是要喜提NullPointException了…

作為JAVA開發(fā)中最典型的異常類型，甚至可能是很多程序員入行之后收到的第一份異常大禮包類型。而NullPointException也似乎成為了一種魔咒，迫使程序員在敲出的每一行代碼的時候都需要去思考下是否需要去做一下判空操作，久而久之，代碼中便充斥著大量的null檢查邏輯。

于是呢，上面的代碼會變成下面這樣：

public void getCompanyFromEmployee() { Employee employee = getEmployee(); if (employee == null) { // do something here… return; } Team team = employee.getTeam(); if (team == null) { // do something here… return; } Department department = team.getDepartment(); if (department == null) { // do something here… return; } Company company = department.getCompany(); System.out.println(company);}

是不是大家的項目中都有見過這種寫法的？每行代碼中都流露著對NullPointException的恐懼有木有？是不是像極了一顆被深深傷害過的心在小心翼翼地保護著自己？

null的困擾

通過上面代碼示例，我們可以發(fā)現(xiàn)使用null可能會帶來的一系列困擾：

• 空指針異常，導致代碼運行時變得不可靠，稍不留神可能就崩了
• 使代碼膨脹，導致代碼中充斥大量的null檢查與保護，使代碼可讀性降低

此外，null還有一個明顯的弊端：

• 含義不明確，比如一個方法返回了null，調(diào)用方不清楚到底是因為邏輯有問題導致為null，還是說null其實也是一種可以接受的正常返回值類型？

所以說，一個比較好的編碼習慣，是盡量避免在程序中使用null，可以按照具體的場景分開區(qū)別對待：

• 確定是因為代碼或者邏輯層面處理錯誤導致的無值，通過throw異常的方式，強制調(diào)用方感知并進行處理對待
• 如果null代表業(yè)務上的一種正?？蛇x值，可以考慮返回Optional來替代。

當然咯，有時候即使我們自己的代碼不返回null，也難免會遇到調(diào)用別人的接口返回null的情況，這種時候我們真的就只能不停的去判空來保護自己嗎？有沒有更優(yōu)雅的應對策略來避免自己掉坑呢？下面呢，我們一起探討下null的一些優(yōu)雅應對策略。

Optional應對null處理

Optional一定比return null安全嗎

前面我們提到了說使用Optional來替代null，減少調(diào)用端的判空操作壓力，防止調(diào)用端出現(xiàn)空指針異常。

那么，使用返回Optional對象就一定會比return null更靠譜嗎？

答案是：也不一定，關鍵要看怎么用！

比如：下面的代碼，getContent()方法返回了個Optional對象，然后testCallOptional()方法作為調(diào)用方，獲取到返回值后的操作方式：

public void testCallOptional() { Optional optional = getContent(); System.out.println(“——-下面代碼會報異常——–“); try { // 【錯誤用法】直接從Optional對象中get()實際參數(shù)，這種效果與返回null對象然后直接調(diào)用是一樣的效果 Content content = optional.get(); System.out.println(content); } catch (Exception e) { e.printStackTrace(); } System.out.println(“——-上面代碼會報異常——–“);}private Optional getContent() { return Optional.ofNullable(null);}

上述代碼運行之后會發(fā)現(xiàn)報錯了：

——-下面代碼會報異常——–java.util.NoSuchElementException: No value presentat java.util.Optional.get(Optional.java:135)at com.veezean.skills.optional.OptionalService.testCallOptional(OptionalService.java:47)at com.veezean.skills.optional.OptionalService.main(OptionalService.java:58)——-上面代碼會報異常——–

既然直接調(diào)用Optional.get()報錯，那就是調(diào)用前加個判斷就好咯？

public void testCallOptional2() { Optional optional = getContent(); // 使用前先判斷下元素是否存在 if (optional.isPresent()) { Content content = optional.get(); System.out.println(content); }}

執(zhí)行一下，果然不報錯了。但是，這樣真的就是解決方法嗎？這樣跟直接返回null然后使用前判空（下面的寫法）其實也沒啥區(qū)別，也并不會讓調(diào)用方使用起來更加的優(yōu)雅與靠譜：

public void testNullReturn2() { Content content = getContent2(); if (content != null) { System.out.println(content.getValue()); }}

那怎么樣才是正確的使用方式呢，下面一起來看下。

全面認識下Optional

創(chuàng)建Optional對象

Optional對象，可以用來表示一個T類型對象的封裝，或者也可以表示不是任何對象。Optional類提供了幾個靜態(tài)方法供對象的構建：

在項目中，我們可以選擇使用上面的方法，實現(xiàn)Optional對象的封裝：

public void testCreateOptional() { // 使用Optional.of構造出具體對象的封裝Optional對象 System.out.println(Optional.of(new Content(“111″,”JiaGouWuDao”))); // 使用Optional.empty構造一個不代表任何對象的空Optional值 System.out.println(Optional.empty()); System.out.println(Optional.ofNullable(null)); System.out.println(Optional.ofNullable(new Content(“222″,”JiaGouWuDao22”)));}

輸出結果：

Optional[Content{id=’111′, value=’JiaGouWuDao’}]Optional.emptyOptional.emptyOptional[Content{id=’222′, value=’JiaGouWuDao22′}]

這里需要注意下of方法如果傳入null會拋空指針異常，所以比較建議大家使用ofNullable方法，可以省去調(diào)用前的額外判空操作，也可以避免無意中觸發(fā)空指針問題：

Optional常用方法理解

在具體討論應該如何正確使用Optional的方法前，先來了解下Optional提供的一些方法：

看到這里的map與flatMap方法，不知道大家會不會聯(lián)想到Stream流對象操作的時候也有這兩個方法的身影呢（不了解的同學可以戳這個鏈接抓緊補補課：吃透JAVA的Stream流操作）？的確，它們的作用也是類似的，都是用來將一個對象處理轉(zhuǎn)換為另一個對象類型的：

對于Optional而言,map與flatMap最終的實現(xiàn)效果其實都是一樣的，僅僅只是入?yún)⒌囊蟛灰粯?，也即兩種不同寫法，兩者區(qū)別點可以通過下圖來理解：

實際使用的時候，可以根據(jù)需要選擇使用map或者flatMap：

public void testMapAndFlatMap() { Optional userOptional = getUser(); Optional employeeOptional = userOptional.map(user -> { Employee employee = new Employee(); employee.setEmployeeName(user.getUserName()); // map與flatMap的區(qū)別點：此處return的是具體對象類型 return employee; }); System.out.println(employeeOptional); Optional employeeOptional2 = userOptional.flatMap(user -> { Employee employee = new Employee(); employee.setEmployeeName(user.getUserName()); // map與flatMap的區(qū)別點：此處return的是具體對象的Optional封裝類型 return Optional.of(employee); }); System.out.println(employeeOptional2);}

從輸出結果可以看出，兩種不同的寫法，實現(xiàn)是相同的效果：

Optional[Employee(employeeName=JiaGouWuDao)]Optional[Employee(employeeName=JiaGouWuDao)]

Optional使用場景

減少繁瑣的判空操作

再回到本篇文章最開始的那段代碼例子，如果我們代碼里面不去逐個做判空保護的話，我們可以如何來實現(xiàn)呢？看下面的實現(xiàn)思路：

public void getCompanyFromEmployeeTest() { Employee employeeDetail = getEmployee(); String companyName = Optional.ofNullable(employeeDetail) .map(employee -> employee.getTeam()) .map(team -> team.getDepartment()) .map(department -> department.getCompany()) .map(company -> company.getCompanyName()) .orElse(“No Company”); System.out.println(companyName);}

先通過map的方式一層一層的去進行類型轉(zhuǎn)換，最后使用orElse去獲取Optional中最終處理后的值，并給定了數(shù)據(jù)缺失場景的默認值。是不是看著比一堆if判空操作要舒服多了？

適用場景：需要通過某個比較長的調(diào)用鏈路一層一層去調(diào)用獲取某個值的時候，使用上述方法，可以避免空指針以及減少冗長的判斷邏輯。

需要有值兜底的數(shù)據(jù)獲取場景

編碼的時候，經(jīng)常會遇到一些數(shù)據(jù)獲取的場景，需要先通過一些處理邏輯嘗試獲取一個數(shù)據(jù)，如果沒有獲取到需要的數(shù)據(jù)，還需要返回一個默認值，或者是執(zhí)行另一處理邏輯繼續(xù)嘗試獲取。

比如從請求頭中獲取客戶端IP的邏輯，按照常規(guī)邏輯，代碼會寫成下面這樣：

public String getClientIp(HttpServletRequest request) { String clientIp = request.getHeader(“X-Forwarded-For”); if (!StringUtils.isEmpty(clientIp)) { return clientIp; } clientIp = request.getHeader(“X-Real-IP”); return clientIp;}

但是借助Optional來實現(xiàn)，可以這樣寫：

public String getClientIp2(HttpServletRequest request) { String clientIp = request.getHeader(“X-Forwarded-For”); return Optional.ofNullable(clientIp).orElseGet(() -> request.getHeader(“X-Real-IP”));}

適用場景：優(yōu)先執(zhí)行某個操作嘗試獲取數(shù)據(jù)，如果沒獲取到則去執(zhí)行另一邏輯獲取，或者返回默認值的場景。

替代可能為null的方法返回值

下面是一段從項目代碼中截取的片段：

public FileInfo queryOssFileInfo(String fileId) { FileEntity entity = fileRepository.findByIdAndStatus(fileId, 0); if (entity != null) { return new FileInfo(entity.getName(), entity.getFilePath(), false); } FileHistoryEntity hisEntity = fileHisRepository.findByIdAndStatus(fileId, 0); if (hisEntity != null) { return new FileInfo(hisEntity.getName(), hisEntity.getFilePath(), true); } return null;}

可以看到最終的return分支中，有一種可能會返回null，這個方法作為項目中被高頻調(diào)用的一個方法，意味著所有的調(diào)用端都必須要做判空保護?？梢允褂肙ptional進行優(yōu)化處理:

public Optional queryOssFileInfo(String fileId) { FileEntity entity = fileRepository.findByIdAndStatus(fileId, 0); if (entity != null) { return Optional.ofNullable(new FileInfo(entity.getName(), entity.getFilePath(), false)); } FileHistoryEntity hisEntity = fileHisRepository.findByIdAndStatus(fileId, 0); if (hisEntity != null) { return Optional.ofNullable(new FileInfo(hisEntity.getName(), hisEntity.getFilePath(), true)); } return Optional.empty();}

這樣的話，就可以有效地防止調(diào)用端踩雷啦~

適用場景：實現(xiàn)某個方法的時候，如果方法的返回值可能會為null，則考慮將方法的返回值改為Optional類型，原先返回null的場景，使用Optional.empty()替代。

包裝數(shù)據(jù)實體中非必須字段

首先明確一下，Optional的意思是可選的，也即用于標識下某個屬性可有可無的特性。啥叫可有可無？看下面代碼：

public class PostDetail { private String title; private User postUser; private String content; private Optional lastModifyTime = Optional.empty(); private Optional attachment = Optional.empty();}

上面是一個帖子詳情數(shù)據(jù)類，對于一個論壇帖子數(shù)據(jù)而言，帖子的標題、內(nèi)容、發(fā)帖人這些都是屬于必須的字段，而帖子的修改時間、帖子的附件其實是屬于可選字段（因為不是所有的帖子都會被修改、也不是所有帖子都會帶附件），所以針對這種可有可無的字段，就可以聲明定義的時候使用Optional進行封裝。

使用Optional進行封裝之后有兩個明顯的優(yōu)勢：

• 強烈的業(yè)務屬性說明，明確的讓人知曉這個是一個可選字段，等同于數(shù)據(jù)庫建表語句里面設置nullable標識一樣的效果；
• 調(diào)用端使用的時候也省去了判空操作。

適用場景：數(shù)據(jù)實體定義的時候，對于可選參數(shù)，采用Optional封裝類型替代。

使用拋異常替代return null

相比于返回一個Optional封裝的對象，直接拋異常具有強烈的警醒意味，意在表達此處存在預期之外的不合理情況，要求編碼的時候，調(diào)用端必須要予以專門處理。

public Team getTeamInfo() throws TestException { Employee employee = getEmployee(); Team team = employee.getTeam(); if (team == null) { throw new TestException(“team is missing”); } return team;}

相比直接return null，顯然拋異常的含義更加明確。

JDK與開源框架的實踐

JDK提供的很多方法里面，其實都是遵循著本文中描述的這種返回值處理思路的，很少會看到直接返回null的——不止JDK，很多大型的開源框架源碼中，也很少會看到直接return null的情況。

比如com.sun.jmx.snmp.agent中的一段代碼：

public SnmpMibSubRequest nextElement() throws NoSuchElementException { if (iter == 0) { if (handler.sublist != null) { iter++; return hlist.getSubRequest(handler); } } iter ++; if (iter > size) throw new NoSuchElementException(); SnmpMibSubRequest result = hlist.getSubRequest(handler,entry); entry++; return result;}

再比如Spring中org.springframework.data.jpa.repository.support包下面的方法例子：

public Optional findById(ID id) {Assert.notNull(id, ID_MUST_NOT_BE_NULL);Class domainType = getDomainClass();if (metadata == null) {return Optional.ofNullable(em.find(domainType, id));}LockModeType type = metadata.getLockModeType();Map hints = getQueryHints().withFetchGraphs(em).asMap();return Optional.ofNullable(type == null ? em.find(domainType, id, hints) : em.find(domainType, id, type, hints));}

總結

好啦，關于編碼中對null的一些應對處理策略與思路呢，這里就給大家分享到這里，希望可以對大家有所啟發(fā)，通過不斷的細節(jié)優(yōu)化與改進，最終擺脫被空指針擺布的局面~

那么，對上面提到的一些內(nèi)容與場景，你是否也有遇到相關的情況呢？你是怎么處理的呢？歡迎多切磋交流下~

此外：

• 關于本文中涉及的演示代碼的完整示例，我已經(jīng)整理并提交到github中，如果您有需要，可以自?。篽ttps://github.com/veezean/JavaBasicSkills

我是悟道，聊技術、又不僅僅聊技術~

如果覺得有用，請點個關注，也可以關注下我的公眾號【架構悟道】，獲取更及時的更新。

期待與你一起探討，一起成長為更好的自己。