Scala中优雅的处理Null问题

前言

如果在scala代码还在使用id! = null,可能会被有的人嘲笑,都什么年代了,竟然还有这样的写法,NullPointerException见少了吧?

不过,据统计:

Spark 源代码使用了 821 次 Option 关键字,但它有直接使用如if (id != 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函数是别人写的,你是个使用者,你一定会遇到如下问题:

  1. 你没有读API文档,根本不知道toInt可能会返回一个null,并且可能你写的代码会抛出NullPointerException
  2. 你读了API文档,并且也有很多使用这个函数的经验,知道它可能会返回null,因此你肯定会写如下代码来处理可能出现的空指针异常
Integer i = toInt(someString);
if (i == null) {
    System.out.println("您输入的字符串无法转为数字");
} else {
    System.out.println(i);
}

该代码并不比 Scala的Option和match方法差,但你确实必须阅读API文档才能知道必须得这样处理。

  1. 当然还可以通过抛出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的缺点

有的人会说,你前言中都说了连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。

收藏 (0)
评论列表
正在载入评论列表...
我是有底线的
为您推荐
    暂时没有数据