程序员最深恶痛绝并力求避免的异常是NullPointerException，很不幸，我们往往又会忽略这个错误。不知是谁设计了Null这样的对象。我在文章《并非null这么简单》中已经阐释了这个问题。然而不仅仅是空指针异常，当程序代码中出现各种错误时，我们的处理方式该如何呢？
现在，让我们再看看Scala语法层面的Option。Option对象并没有从根本上解决程序错误的问题，但只要使用得当，就能有效地将错误往程序的外层推，这实际上是消除副作用的惯常做法。正如Paul Chiusano等人的著作《Scala函数式编程》描述的那样：
对函数式程序员而言，程序的实现，应该有一个纯的内核和一层很薄的外围来处理副作用。
REA的Scala程序员Ken Scambler在YOW!大会上有一个很棒的演讲2 Year of Real World FP at REA。演讲中提到REA选择函数式编程的三个原因：
- 模块化(Modularity)
- 抽象(Abstraction)
- 可组合性(Composability)
模块化的一个重要特征是设计没有副作用的纯函数，这样就不会影响调用该纯函数的上下文，也就是所谓的“引用透明(Reference Transparency)”概念，即针对任何函数都可以使用它的返回值来代替（substitution）。
Ken Scambler使用了一个解析字符串的例子来阐释这种纯函数特质。如下代码所示：
def parseLocation(str: String): Location = { val parts = str.split(",") val secondStr = parts(1) val parts2 = secondStr.split(“ “) Location( parts(0), parts2(0), parts(1).toInt) }
这段代码可能存在如下错误：
- 作为input的str可能为null
- parts(0)和parts(1)可能导致索引越界
- parts2(0)可能导致索引越界
- parts(1)未必是整数，调用toInt可能导致类型转换异常
仅仅从函数的定义来看，我们其实看不到这些潜在的负面影响。那么，想像一下当这样的方法被系统中许多地方直接或间接调用，可能会造成什么样的灾难？！假设这样的代码被放到安全要求极高的系统中，你是否会感到不寒而栗？——程序员，应该在道义上肩负为自己所写每行代码承担自己的责任，这是基本的职业素养。我所谓的承担责任，并不是事后追究，而是在每次写完代码后都要再三推敲，力求每行代码都是干净利落，没有歧义，没有潜在的错误。
然而，针对以上代码，要怎样才能保证程序调用的健壮性呢？就是要对可能出现的错误（空对象，索引越界，类型转换异常）进行判断。这就需要在parseLocation函数体中加入一堆if语句，短短的六行代码可能会膨胀一倍，而分支语句也会让程序的逻辑变得凌乱，正常逻辑与异常逻辑可能会像麻花一样扭在一起。当然，我们可以运用防御式编程，将可能的错误防御在正常逻辑代码之前，但它带来的阅读体验却会非常糟糕。
即使针对这些错误进行判断，仍然无法解决的一个问题是当对象真的出现错误时，函数实现究竟该如何处理？多数语言不支持多返回值（乃至不支持类似Scala的Pair），经典的解决办法就是抛出异常，可惜，异常却存在副作用。许多程序员更习惯性的返回了null。这是最要命的做法，就好像是慕容复的“以彼之道，还施彼身”，典型地损人利己！
引入Option，会让代码在保证健壮性的同时还保证了简洁性，例如：
def parseLocation(str: String): Option[Location] = { val parts = str.split(",") for { locality <- parts.optGet(0) theRestStr <- parts.optGet(1) theRest = theRestStr.split(" ") subdivision <- theRest.optGet(0) postcodeStr <- theRest.optGet(1) postcode <- postcodeStr.optToInt } yield Location(locality, subdivision, postcode)}
本质上，Option是一个Monad；简单来说，是一个定义了flatMap与map的容器，故而能够支持Scala中可读性更佳的for comprehension。如上代码简单明了，你甚至可以忽略当Option为None的情形，只考虑正常的字符串解析逻辑，它自然地隐含了None的语义，因为在代码中通过optGet与optToInt返回的值（为Option类型），只要其中一个为None，整个函数就将即刻返回一个None对象，而非一个包裹了Location的Some对象。这样既避免了使用分支语句，还能使得函数没有任何副作用，规避了抛出异常的逻辑。
如上的改进仍然存在一个问题，那就是缺乏对输入的str进行判断。一个好的API设计者或者函数实现者，要怀着“性本恶”的悲观主义道德观，对任何输入持怀疑态度，且不惮于怀疑调用者的恶意。对于输入的这个str，我们仍然要避免使用条件判断的方式，因而可以修改函数的接口为：
def parseLocation(str: Option[String]): Option[Location] = ???
如此，我们可以将对str的解析逻辑也挪动到for comprehension中：
def parseLocation(str: Option[String]): Option[Location] = { for { val parts = str.split(",") locality <- parts.optGet(0) theRestStr <- parts.optGet(1) theRest = theRestStr.split(" ") subdivision <- theRest.optGet(0) postcodeStr <- theRest.optGet(1) postcode <- postcodeStr.optToInt } yield Location(locality, subdivision, postcode)}
使用Option的唯一问题是：你虽然指定了Option这样的游戏规则，但其他API的设计者却未必按照你设计的规则出牌。这也是如上代码中optGet之类函数的由来。即使是Scala的内置库，如String的split函数，返回的也并非一个Option，而是一个普通的数组。当我们给一个错误的下标值去访问数组时，有可能会抛出ArrayIndexOutOfBoundsException异常。
Scala提供的解决方案是隐式转换（implicit conversion）。split()函数返回的类型为Array[String]，该类型自身是没有optGet()函数的。但是我们可以为Array[String]定义隐式转换：
implicit class ArrayWrapper(array: Array[String]) { def optGet(index:Int): Option[String] = if (array.length > index) Some(array(index)) else None }
optToInt方法可以如法炮制。
惯常说来，当我们在使用Option时，习惯于利用模式匹配（pattern match）以运用“分而治之”的思想来编写代码。然而，多数时候我们应该使用定义在Option中的函数，这些函数可以让代码变得更简单。例如使用flatMap、map、isDefined、isEmpty、forAll、exists、orElse、getOrElse等函数。Tony Morris整理的scala.Option Cheat Sheet总结了这些函数的用法，可供参考。
