Atitit. null错误的设计 使用Optional来处理null
然后，我们再看看null还会引入什么问题。
看看下面这个代码：
String address = person.getCountry().getProvince().getCity();
如果你玩过一些函数式语言（Haskell、Erlang、Clojure、Scala等等），上面这样是一种很自然的写法。用Java当然也可以实现上面这样的编写方式。
但是为了完满的处理所有可能出现的null异常，我们不得不把这种优雅的函数编程范式改为这样：
if (person != null) {
Country country = person.getCountry();
if (country != null) {
Province province = country.getProvince();
if (province != null) {
address = province.getCity();
}
}
}
瞬间，高逼格的函数式编程Java8又回到了10年前。这样一层一层的嵌套判断，增加代码量和不优雅还是小事。更可能出现的情况是：在大部分时间里，人们会忘记去判断这可能会出现的null，即使是写了多年代码的老人家也不例外。
作者:: ★(attilax)>>> 绰号:老哇的爪子 （ 全名：：Attilax Akbar Al Rapanui 阿提拉克斯 阿克巴 阿尔 拉帕努伊 ） 汉字名：艾龙， EMAIL:1466519819@qq.com
转载请注明来源： http://blog.csdn.net/attilax
我们看看前面提到的Person.getCountry().getProvince().getCity()怎么不用一堆if来处理。
第一种方法是不改变以前的entity：
这里用Optional作为每一次返回的外壳，如果有某个位置返回了null，则会直接得到"unkonwn"。
第二种办法是将所有的值都用Optional来定义：
第一种方法可以平滑的和已有的JavaBean、Entity或POJA整合，而无需改动什么，也能更轻松的整合到第三方接口中（例如spring的bean）。建议目前还是以第一种Optional的使用方法为主，毕竟不是团队中每一个人都能理解每个get/set带着一个Optional的用意。
Optional还提供了一个filter方法用于过滤数据（实际上Java8里stream风格的接口都提供了filter方法）。例如过去我们判断值存在并作出相应的处理：
Java函数式开发——优雅的Optional空指针处理 - 随风溜达的向日葵 - 开源中国社区.html