Scala中優雅的處理Null問題

2021-08-30 16:01:08

前言

如果在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

def toInt(in: String): Option[Int] = {
  try {
    Some(Integer.parseInt(in.trim))
  } catch {
    case e: NumberFormatException => None
  }
}

如何使用這個函數：

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，因此你肯定會寫如下程式碼來處理可能出現的空指標異常

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，有的不可以

val bag = List("1", "2", "foo", "3", "bar")

要實現這個需求，感覺要寫很多程式碼才能實現，其實在scala中只要一行程式碼就可以實現:

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 （不過它是寫出發生問題的原因）

還是搞一段程式碼來解釋

/**
  * 這裡寫個簡單的方法來演示，如何寫一個返回值為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內容請搜尋it145.com以前的文章或繼續瀏覽下面的相關文章希望大家以後多多支援it145.com！