是時候優雅的和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類提供了幾個靜態方法供物件的構建：
| 方法名 | 功能含義描述 |
|---|---|
| empty() | 構造一個無任何實際物件值的空Optional物件（可以理解為業務層面的null） |
| of(T t) | 根據給定的物件，構造一個此物件的封裝Optional物件，注意入參t不能為null，否則會空指標 |
| ofNullable(T t) | 根據傳入的入參t的值構造Optional封裝物件，如果傳入的t為null，則等同於呼叫empty()方法，如果t不為null，則等同於呼叫of(T t)方法 |
在專案中，我們可以選擇使用上面的方法，實現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.empty
Optional.empty
Optional[Content{id='222', value='JiaGouWuDao22'}]
這裡需要注意下of方法如果傳入null會拋空指標異常，所以比較建議大家使用ofNullable方法，可以省去呼叫前的額外判空操作，也可以避免無意中觸發空指標問題：
Optional常用方法理解
在具體討論應該如何正確使用Optional的方法前，先來了解下Optional提供的一些方法：
| 方法名 | 含義說明 |
|---|---|
| isPresent | 如果Optional實際有具體物件值，則返回true，否則返回false。 |
| ifPresent | 這是一個函數語言程式設計風格的API介面，入參是一個函式，即如果Optional物件有實際物件值，則會執行傳入的入參函式邏輯，如果不存在實際物件值，則不會執行傳入的入參函式邏輯。 |
| get | 返回Optional封裝的實際物件T資料，注意，如果實際物件資料不存在，會拋異常而非返回null |
| orElse | 與get方法類似，都是獲取Optional實際的物件值，區別在於orElse必須傳入一個預設值，當Optional沒有實際值的時候返回預設值而非拋異常 |
| orElseGet | 可以理解為orElse方法的升級版，區別在於orElse僅允許傳入一個固定的預設值，而orElseGet的入參是一個函式方法，當Optional無實際值時，會執行給定的入參函式，返回動態值。 |
| orElseThrow | 與orElse類似，區別在於如果沒有獲取到，會丟擲一個指定的異常。 |
| filter | 判定當前Optional的實際物件是否符合入參函式的過濾規則，如果符合則返回當前Optional物件，如果不符合則返回空Optional |
| map | 接收一個入參函式，允許將Optional中的實際物件值處理轉換為另一實際物件值（這個入參函式的返回值為T），並生成返回此新型別的Optional物件，如果生成的新物件為null，則返回一個空Optional物件 |
| flatMap | 與map類似，區別點在於入參函式的返回值型別有區別（此處入參函式的返回值為Optional<T>） |
看到這裡的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 == null) {
return Optional.ofNullable(em.find(domainType, id));
}
LockModeType type = metadata.getLockModeType();
Map<String, Object> 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
我是悟道，聊技術、又不僅僅聊技術~
如果覺得有用，請點個關注，也可以關注下我的公眾號【架構悟道】，獲取更及時的更新。
期待與你一起探討，一起成長為更好的自己。
