前言
如果在scala代碼還在使用ids!=null,可能會被有的人嘲笑,都什么年代了,竟然還有這樣的寫法,NullPointerException見少了吧?
不過,據統計:
Spark 源代碼使用了 821 次 Option 關鍵字,但它也直接在像if (ids != null)。
Spark 采用混合方式,大部分情況下使用 Option,但個別時候出于性能(這里主要是為了給使用這返回提示信息)原因才使用了null。
一個很好的習慣是當有方法返回值可能為null的時候,使用Option來代替。
什么是Option
標準類庫中Option類型用樣例類來表示那種可能存在、也可能不存在的值。
Option的有兩個子類,Some 和 None,Some包裝了某個值,如Some(“Jack”),而None表示沒有值。
有的小伙伴看到依然云里霧里的,因此直接上一個簡單的例子,來感受一下這個Option究竟是什么東西:
煮個栗子
這里寫了一個把字符串轉為數值的方法,輸入的是字符串,輸出的這里注意一下,并不是直接輸出Int,而且一個泛型為Int的Option
1
2
3
4
5
6
7
|
def toInt(in: String): Option[Int] = { try { Some(Integer.parseInt(in.trim)) } catch { case e: NumberFormatException => None } } |
如何使用這個函數:
1
2
3
4
|
toInt( "s" ) match { case Some(i) => println(i) case None => println( "您輸入的字符串無法轉為數字" ) } |
簡單的總結一下這個Option的使用,其實就是把你原本要返回的類型,直接返回泛型為該類型的Option,然后寫正常返回值的時候返回Some,異常的時候返回None即可。而調用方法的時候,需要用到match case分別做處理。
有人看到這里可能會抱怨:一個簡單的null判斷,寫了這么一大堆,還不如java中的直接用i!=null來判斷簡單粗暴呢。
但是如果這個toInt函數是別人寫的,你是個使用者,你一定會遇到如下問題:
- 你沒有讀API文檔,根本不知道toInt可能會返回一個null,并且可能你寫的代碼會拋出NullPointerException
- 你讀了API文檔,并且也有很多使用這個函數的經驗,知道它可能會返回null,因此你肯定會寫如下代碼來處理可能出現的空指針異常
1
2
3
4
5
6
|
Integer i = toInt(someString); if (i == null ) { System.out.println( "您輸入的字符串無法轉為數字" ); } else { System.out.println(i); } |
該代碼并不比 Scala的Option和match方法差,但你確實必須閱讀API文檔才能知道必須得這樣處理。
3.當然還可以通過拋出NumberFormatException來處理null或者其他一些異常情況
Option的好處不僅如此
比如想統計下面list中的總和,這些字符串有的可以轉為Int,有的不可以
1
|
val bag = List( "1" , "2" , "foo" , "3" , "bar" ) |
要實現這個需求,感覺要寫很多代碼才能實現,其實在scala中只要一行代碼就可以實現:
1
|
val sum = bag.flatMap(toInt).sum |
為什么可以這么簡單的就實現:
我們的toInt方法返回的是Some[Int]或None,而flatMap知道如何處理這些值,所以實現起來就小菜一碟了,而且還很容易閱讀和理解。
這就是使用Option/Some/None 模式真正牛叉的地方了
簡單的總結java null 與 scala Option
如果你用別人寫的java方法,那么一般需要閱讀API文檔,或者是使用后拋出了NullPointException后,查文檔和資料發現,需要處理這個空指針異常。那么scala Option我們在使用函數的時候,可以看到返回值是個Option[Int](直接在IDE中就能看到返回值類型,不需要去閱讀該函數的API文檔),說明開發這個函數的人一定用了Option/Some/None這一套組合拳,因此就知道用match case來解決了。
在我看來,其實從寫代碼的角度來看代碼量并沒有減少,優點有兩:
- 更具有可讀性,
- 避免在使用函數的時候,出現空指針異常 Option的缺點
Option的缺點
有的人會說,你前言中都說了連spark源碼都不是一律采用Option來處理null值,你既然上面吹的神乎其神的,人家干嘛不全部用Option?
這里就得說一下Option的一個缺點:
無法說出某件事失敗的原因(也就是為什么你得到了一個None而不是一個Some),因為根本就看不到錯誤異常信息
對此scala 的解決方案是使用Either Left 和 Right來處理異常信息
Either Left Right簡介與使用
Either其實用起來和Option很像,不同的是Either可以返回一個字符串來描述發生的問題。
Either 和Option的比較:
Either 就像 Option
Right 就像 Some
Left 就像 None (不過它是寫出發生問題的原因)
還是搞一段代碼來解釋
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
/** * 這里寫個簡單的方法來演示,如何寫一個返回值為Either的方法 * 以及Either中Left和Right的用法 */ def divideXByY(x: Int, y: Int): Either[String, Int] = { if (y == 0 ) Left( "零不能作為除數" ) else Right(x / y) } // 使用 Either, Left, and Right的幾種不同方式 println(divideXByY( 1 , 0 )) println(divideXByY( 1 , 1 )) divideXByY( 1 , 0 ) match { case Left(s) => println( "Answer: " + s) case Right(i) => println( "Answer: " + i) } |
上面divideXByY方法返回的是一個Either[String, Int],這個泛型String就是Left方法中傳入的數據類型,而Int就是Right方法傳入的數據類型。
通過上面的例子,會發現這一套東西和Option/Some/None使用起來很像,唯一不同的是,Either將出錯的信息可以傳回,使用者可以看到異常信息。我們看看官網是怎么說的:
Represents a value of one of two possible types (a disjoint union.) Instances of Either are either an instance of Left or Right.
A common use of Either is as an alternative to Option for dealing with possible missing values. In this usage,
scala.None is replaced with a Left which can contain useful information. Right takes the place of Some.
Convention dictates that Left is used for failure and Right is used for success.
說白了就是我上面寫的,如果要返回錯誤信息給使用者,就用Either。不過根據我經驗,一般這樣的場景不算多。因此最長用的還是Option。
到此這篇關于Scala中如何優雅的處理Null的文章就介紹到這了,更多相關Scala處理Null內容請搜索服務器之家以前的文章或繼續瀏覽下面的相關文章希望大家以后多多支持服務器之家!
原文鏈接:https://blog.csdn.net/Android_xue/article/details/119972710