是時候優雅的和NullPointException說再見了

是時候優雅的和NullPointException說再見了
????????????????????????????????
最近在參加原創投稿比賽，本篇文章如果對你有幫助的話，歡迎幫忙點擊助力下吧

NullPointException應該算是每一個碼農都很熟悉的家伙了吧？誰的代碼不曾拋過幾個空指標例外呢...

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

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開發中最典型的例外型別，甚至可能是很多程式員入行之后收到的第一份例外大禮包型別，而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的困擾

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

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

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

• 含義不明確，比如一個方法回傳了null，呼叫方不清楚到底是因為邏輯有問題導致為null，還是說null其實也是一種可以接受的正常回傳值型別？

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

• 確定是因為代碼或者邏輯層面處理錯誤導致的無值，通過throw例外的方式，強制呼叫方感知并進行處理對待
• 如果null代表業務上的一種正常可選值，可以考慮回傳Optional來替代，

當然咯，有時候即使我們自己的代碼不回傳null，也難免會遇到呼叫別人的介面回傳null的情況，這種時候我們真的就只能不停的去判空來保護自己嗎？有沒有更優雅的應對策略來避免自己掉坑呢？下面呢，我們一起探討下null的一些優雅應對策略，

Optional應對null處理

Optional一定比return null安全嗎

前面我們提到了說使用Optional來替代null，減少呼叫端的判空操作壓力，防止呼叫端出現空指標例外，

那么，使用回傳Optional物件就一定會比return null更靠譜嗎？

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

比如：下面的代碼，getContent()方法回傳了個Optional物件，然后testCallOptional()方法作為呼叫方，獲取到回傳值后的操作方式：

public void testCallOptional() {
    Optional<Content> optional = getContent();
    System.out.println("-------下面代碼會報例外--------");
    try {
        // 【錯誤用法】直接從Optional物件中get()實際引數，這種效果與回傳null物件然后直接呼叫是一樣的效果
        Content content = optional.get();
        System.out.println(content);
    } catch (Exception e) {
        e.printStackTrace();
    }
    System.out.println("-------上面代碼會報例外--------");
}

private Optional<Content> getContent() {
    return Optional.ofNullable(null);
}

上述代碼運行之后會發現報錯了：

-------下面代碼會報例外--------
java.util.NoSuchElementException: No value present
	at 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)
-------上面代碼會報例外--------

既然直接呼叫Optional.get()報錯，那就是呼叫前加個判斷就好咯？

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

執行一下，果然不報錯了，但是，這樣真的就是解決方法嗎？這樣跟直接回傳null然后使用前判空（下面的寫法）其實也沒啥區別，也并不會讓呼叫方使用起來更加的優雅與靠譜：

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

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

全面認識下Optional

創建Optional物件

Optional<T>物件，可以用來表示一個T型別物件的封裝，或者也可以表示不是任何物件，Optional類提供了幾個靜態方法供物件的構建：

在專案中，我們可以選擇使用上面的方法，實作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='https://www.cnblogs.com/softwarearch/p/JiaGouWuDao'}]
Optional.empty
Optional.empty
Optional[Content{id='222', value='https://www.cnblogs.com/softwarearch/p/JiaGouWuDao22'}]

這里需要注意下of方法如果傳入null會拋空指標例外，所以比較建議大家使用ofNullable方法，可以省去呼叫前的額外判空操作，也可以避免無意中觸發空指標問題：

Optional常用方法理解

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

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

對于Optional而言,map與flatMap最終的實作效果其實都是一樣的，僅僅只是入參的要求不一樣，也即兩種不同寫法，兩者區別點可以通過下圖來理解：

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

public void testMapAndFlatMap() {
    Optional<User> userOptional = getUser();
    Optional<Employee> employeeOptional = userOptional.map(user -> {
        Employee employee = new Employee();
        employee.setEmployeeName(user.getUserName());
        // map與flatMap的區別點：此處return的是具體物件型別
        return employee;
    });
    System.out.println(employeeOptional);

    Optional<Employee> employeeOptional2 = userOptional.flatMap(user -> {
        Employee employee = new Employee();
        employee.setEmployeeName(user.getUserName());
        // map與flatMap的區別點：此處return的是具體物件的Optional封裝型別
        return Optional.of(employee);
    });
    System.out.println(employeeOptional2);
}

從輸出結果可以看出，兩種不同的寫法，實作是相同的效果：

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

Optional使用場景

減少繁瑣的判空操作

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

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的方式一層一層的去進行型別轉換，最后使用orElse去獲取Optional中最終處理后的值，并給定了資料缺失場景的默認值，是不是看著比一堆if判空操作要舒服多了？

?? 適用場景：
需要通過某個比較長的呼叫鏈路一層一層去呼叫獲取某個值的時候，使用上述方法，可以避免空指標以及減少冗長的判斷邏輯，

需要有值兜底的資料獲取場景

編碼的時候，經常會遇到一些資料獲取的場景，需要先通過一些處理邏輯嘗試獲取一個資料，如果沒有獲取到需要的資料，還需要回傳一個默認值，或者是執行另一處理邏輯繼續嘗試獲取，

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

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來實作，可以這樣寫：

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

?? 適用場景：
優先執行某個操作嘗試獲取資料，如果沒獲取到則去執行另一邏輯獲取，或者回傳默認值的場景，

替代可能為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，這個方法作為專案中被高頻呼叫的一個方法，意味著所有的呼叫端都必須要做判空保護，可以使用Optional進行優化處理:

public Optional<FileInfo> 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();
}

這樣的話，就可以有效的防止呼叫端踩雷啦~

?? 適用場景：
實作某個方法的時候，如果方法的回傳值可能會為null，則考慮將方法的回傳值改為Optional型別，原先回傳null的場景，使用Optional.empty()替代，

包裝資料物體中非必須欄位

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

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

上面是一個帖子詳情資料類，對于一個論壇帖子資料而言，帖子的標題、內容、發帖人這些都是屬于必須的欄位，而帖子的修改時間、帖子的附件其實是屬于可選欄位（因為不是所有的帖子都會被修改、也不是所有帖子都會帶附件），所以針對這種可有可無的欄位，就可以宣告定義的時候使用Optional進行封裝，

使用Optional進行封裝之后有兩個明顯的優勢：

• 強烈的業務屬性說明，明確的讓人知曉這個是一個可選欄位，等同于資料庫建表陳述句里面設定nullable標識一樣的效果；
• 呼叫端使用的時候也省去了判空操作，

?? 適用場景：
資料物體定義的時候，對于可選引數，采用Optional封裝型別替代，

使用拋例外替代return null

相比于回傳一個Optional封裝的物件，直接拋例外具有強烈的警醒意味，意在表達此處存在預期之外的不合理情況，要求編碼的時候，呼叫端必須要予以專門處理，

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<T> findById(ID id) {
	Assert.notNull(id, ID_MUST_NOT_BE_NULL);
	Class<T> domainType = getDomainClass();
	if (metadata =https://www.cnblogs.com/softwarearch/p/= 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的一些應對處理策略與思路呢，這里就給大家分享到這里，希望可以對大家有所啟發，通過不斷的細節優化與改進，最終擺脫被空指標擺布的局面~

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

??此外：

• 關于本文中涉及的演示代碼的完整示例，我已經整理并提交到github中，如果您有需要，可以自取：https://github.com/veezean/JavaBasicSkills

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

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

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

本文來自博客園，作者：架構悟道，歡迎關注公眾號[架構悟道]持續獲取更多干貨，轉載請注明原文鏈接：https://www.cnblogs.com/softwarearch/p/16478112.html

標籤：Java

上一篇：深入理解Java中的ThreadLocal

下一篇：mybatis-延遲加載