边缘计算的成败关键

我们把接口定义加上了说明之后，调用者会看到，如果调用此接口，很有可能抛出“UserNotFoundException(找不到用户)”这样的异常。

这种方式可以在调用者调用接口的时候看到接口的定义，但是，这种方式是”弱提示”的！

如果调用者忽略了注释，有可能就对业务系统产生了风险，这个风险有可能导致一个亿！

除了以上这种”弱提示”的方式，还有一种方式是，返回值是有可能为空的。那要怎么办呢？

我认为我们需要增加一个接口，用来描述这种场景.

引入jdk8的Optional,或者使用guava的Optional.看如下定义: 

 

段代码返回是null,从我多年的开发经验来讲，对于集合这样返回值，最好不要返回null，因为如果返回了null，会给调用者带来很多麻烦。你将会把这种调用风险交给调用者来控制。

如果调用者是一个谨慎的人，他会进行是否为null的条件判断。如果他并非谨慎，或者他是一个面向接口编程的狂热分子(当然，面向接口编程是正确的方向)，他会按照自己的理解去调用接口，而不进行是否为null的条件判断，如果这样的话，是非常危险的，它很有可能出现空指针异常！

基于此，我们将它进行优化：

 

问题现场

对于面向对象语言来讲，抽象层级特别的重要。尤其是对接口的抽象，它在设计和开发中占很大的比重，我们在开发时希望尽量面向接口编程。

对于以上描述的接口方法来看，大概可以推断出可能它包含了以下两个含义:

•  listUser(): 查询用户列表
•  get(Integerid): 查询单个用户

在所有的开发中，XP推崇的TDD模式可以很好的引导我们对接口的定义，所以我们将TDD作为开发代码的”推动者”。

对于以上的接口，当我们使用TDD进行测试用例先行时，发现了潜在的问题：

•  listUser() 如果没有数据，那它是返回空集合还是null呢？
•  get(Integerid) 如果没有这个对象，是抛异常还是返回null呢？

深入listUser研究

我们先来讨论 

 

场主常听到群里开发兄弟抱怨，实操时经常看到项目中存在到处空值判断的情况，这些判断，会让人觉得摸不着头绪，它的出现很有可能和当前的业务逻辑并没有关系。但着实头疼。。。

有时候，更可怕的是系统因为这些空值的情况，会抛出空指针异常，导致业务系统发生问题。本文总结了几种关于空值的处理手法，分享给大家。

业务中的空值

场景

存在一个 UserSearchService用来提供用户查询的功能： 

（编辑：信阳站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!