Scala中优雅的处理Null问题

Scala中优雅的处理Null问题

目录前言什么是Option煮个栗子Option的好处不仅如此简单的总结java null 与 scala OptionOption的缺点Either Left Right简介与使用

前言

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

SomevTbjjPg(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。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。