是時候優雅的和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
,也難免會遇到呼叫別人的介面返回null的情況,這種時候我們真的就只能不停的去判空來保護自己嗎?有沒有更優雅的應對策略來避免自己掉坑呢?下面呢,我們一起探討下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<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提供的一些方法:
方法名 | 含義說明 |
---|---|
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)]
再回到本篇文章最開始的那段程式碼例子,如果我們程式碼裡面不去逐個做判空保護的話,我們可以如何來實現呢?看下面的實現思路:
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
判空操作要舒服多了?