postman如何设置返回值
postman怎么验证逻辑？
postman怎么验证逻辑？
1.检查response的body中是否包含字符串
2.检查Response Body是否等于字符串
3.检查响应时间
4.检查HTTP请求的状态码
5.检查HTTP请求返回的状态码是否包含相应的字符串
6.设置环境变量/全局变量
7.把XML的body转换成JSON对象
8.检查json的值
9.检查有信息
request状态码
如何优雅的设计Java异常？
异常的类别
正如我们所知道的，java中的异常的超类是(后文省略为Throwable),它有两个比较重要的子类,(后文省略为Exception)和(后文省略为Error)，其中Error由JVM虚拟机进行管理,如我们所熟知的OutOfMemoryError异常等，所以我们本文不关注Error异常，那么我们细说一下Exception异常。
Exception异常有个比较重要的子类，叫做RuntimeException。我们将RuntimeException或其他继承自RuntimeException的子类称为非受检异常(unchecked Exception)，其他继承自Exception异常的子类称为受检异常(checked Exception)。本文重点来关注一下受检异常和非受检异常这两种异常。
如何选择异常
从笔者的开发经验来看，如果在一个应用中，需要开发一个方法(如某个功能的service方法)，这个方法如果中间可能出现异常，那么你需要考虑这个异常出现之后是否调用者可以处理，并且你是否希望调用者进行处理，如果调用者可以处理，并且你也希望调用者进行处理，那么就要抛出受检异常，提醒调用者在使用你的方法时，考虑到如果抛出异常时如果进行处理。
相似的，如果在写某个方法时，你认为这是个偶然异常，理论上说，你觉得运行时可能会碰到什么问题，而这些问题也许不是必然发生的，也不需要调用者显示的通过异常来判断业务流程操作的，那么这时就可以使用一个RuntimeException这样的非受检异常.
好了，估计我上边说的这段话，你读了很多遍也依然觉得晦涩了。
那么，请跟着我的思路，在慢慢领会一下。
什么时候才需要抛异常
首先我们需要了解一个问题，什么时候才需要抛异常？异常的设计是方便给开发者使用的，但不是乱用的，笔者对于什么时候抛异常这个问题也问了很多朋友，能给出准确答案的确实不多。其实这个问题很简单，如果你觉得某些”问题”解决不了了，那么你就可以抛出异常了。
比如，你在写一个service,其中在写到某段代码处,你发现可能会产生问题，那么就请抛出异常吧，相信我，你此时抛出异常将是一个最佳时机。
应该抛出怎样的异常
了解完了什么时候才需要抛出异常后，我们再思考一个问题，真的当我们抛出异常时，我们应该选用怎样的异常呢？究竟是受检异常还是非受检异常呢(RuntimeException)呢？
我来举例说明一下这个问题，先从受检异常说起,比如说有这样一个业务逻辑，需要从某文件中读取某个数据，这个读取操作可能是由于文件被删除等其他问题导致无法获取从而出现读取错误，那么就要从redis或mysql数据库中再去获取此数据,参考如下代码，getKey(Integer)为入口程序.
ok，看了以上代码以后，你也许心中有一些想法，原来受检异常可以控制义务逻辑，对，没错，通过受检异常真的可以控制业务逻辑，但是切记不要这样使用，我们应该合理的抛出异常，因为程序本身才是流程，异常的作用仅仅是当你进行不下去的时候找到的一个借口而已，它并不能当成控制程序流程的入口或出口，如果这样使用的话，是在将异常的作用扩大化，这样将会导致代码复杂程度的增加，耦合性会提高，代码可读性降低等问题。
那么就一定不要使用这样的异常吗？其实也不是，在真的有这样的需求的时候，我们可以这样使用，只是切记，不要把它真的当成控制流程的工具或手段。那么究竟什么时候才要抛出这样的异常呢？要考虑，如果调用者调用出错后，一定要让调用者对此错误进行处理才可以，满足这样的要求时，我们才会考虑使用受检异常。
接下来，我们来看一下非受检异常呢(RuntimeException)，对于RuntimeException这种异常，我们其实很多见，比如／等，那么这种异常我们时候抛出呢？
当我们在写某个方法的时候，可能会偶然遇到某个错误，我们认为这个问题时运行时可能为发生的，并且理论上讲，没有这个问题的话，程序将会正常执行的时候，它不强制要求调用者一定要捕获这个异常，此时抛出RuntimeException异常。
举个例子，当传来一个路径的时候，需要返回一个路径对应的File对象:
上述例子表明，如果调用者调用getFiles(String)的时候如果path是空，那么就抛出空指针异常(它是RuntimeException的子类),调用者不用显示的进行try…catch…操作进行强制处理.这就要求调用者在调用这样的方法时先进行验证，避免发生RuntimeException.如下:
应该选用哪种异常
通过以上的描述和举例，可以总结出一个结论，RuntimeException异常和受检异常之间的区别就是:是否强制要求调用者必须处理此异常，如果强制要求调用者必须进行处理，那么就使用受检异常，否则就选择非受检异常(RuntimeException)。一般来讲，如果没有特殊的要求，我们建议使用RuntimeException异常。
场景介绍和技术选型架构描述
正如我们所知，传统的项目都是以MVC框架为基础进行开发的，本文主要从使用restful风格接口的设计来体验一下异常处理的优雅。
我们把关注点放在restful的api层(和web中的controller层类似)和service层，研究一下在service中如何抛出异常，然后api层如何进行捕获并且转化异常。
使用的技术是:spring-boot,jpa(hibernate),mysql,如果对这些技术不是太熟悉，读者需要自行阅读相关材料。
业务场景描述
选择一个比较简单的业务场景，以电商中的收货地址管理为例，用户在移动端进行购买商品时，需要进行收货地址管理，在项目中，提供一些给移动端进行访问的api接口，如:添加收货地址，删除收货地址，更改收货地址，默认收货地址设置，收货地址列表查询，单个收货地址查询等接口。
构建约束条件
ok，这个是设置好的一个很基本的业务场景，当然，无论什么样的api操作，其中都包含一些规则:
添加收货地址:入参:
用户id
收货地址实体信息
约束:
用户id不能为空，且此用户确实是存在 的
收货地址的必要字段不能为 空
如果用户还没有收货地址，当此收货地址创建时设置成默认收货地址 —
删除收货地址:入参:
用户id
收货地址id
约束:
用户id不能为空，且此用户确实是存在的
收货地址不能为空，且此收货地址确实是存在的
判断此收货地址是否是用户的收货地址
判断此收货地址是否为默认收货地址，如果是默认收货地址，那么不能进行删除
更改收货地址:入参:
用户id
收货地址id
约束:
用户id不能为空，且此用户确实是存在的
收货地址不能为空，且此收货地址确实是存在的
判断此收货地址是否是用户的收货地址
默认地址设置:入参:
用户id
收货地址id
约束:
用户id不能为空，且此用户确实是存在的
收货地址不能为空，且此收货地址确实是存在的
判断此收货地址是否是用户的收货地址
收货地址列表查询:入参:
用户id
约束:
用户id不能为空，且此用户确实是存在的
单个收货地址查询:入参:
用户id
收货地址id
约束:
用户id不能为空，且此用户确实是存在的
收货地址不能为空，且此收货地址确实是存在的
判断此收货地址是否是用户的收货地址
约束判断和技术选型
对于上述列出的约束条件和功能列表，我选择几个比较典型的异常处理场景进行分析:添加收货地址，删除收货地址，获取收货地址列表。
那么应该有哪些必要的知识储备呢，让我们看一下收货地址这个功能:
添加收货地址中需要对用户id和收货地址实体信息就行校验，那么对于非空的判断，我们如何进行工具的选择呢？传统的判断如下:
上边的例子，如果只判断uid为空还好，如果再去判断address这个实体中的某些必要属性是否为空，在字段很多的情况下，这无非是灾难性的。
那我们应该怎么进行这些入参的判断呢，给大家介绍两个知识点:
Guava中的Preconditions类实现了很多入参方法的判断
jsr 303的validation规范(目前实现比较全的是hibernate实现的hibernate-validator)
如果使用了这两种推荐技术，那么入参的判断会变得简单很多。推荐大家多使用这些成熟的技术和jar工具包，他可以减少很多不必要的工作量。我们只需要把重心放到业务逻辑上。而不会因为这些入参的判断耽误更多的时间。
如何优雅的设计java异常domain介绍
根据项目场景来看，需要两个domain模型，一个是用户实体，一个是地址实体.
Address domain如下:
User domain如下:
ok,上边是一个模型关系，用户-收货地址的关系是1-n的关系。上边的@Data是使用了一个叫做lombok的工具，它自动生成了Setter和Getter等方法，用起来非常方便，感兴趣的读者可以自行了解一下。
dao介绍
数据连接层，我们使用了spring-data-jpa这个框架，它要求我们只需要继承框架提供的接口，并且按照约定对方法进行取名，就可以完成我们想要的数据库操作。
用户数据库操作如下:
收货地址操作如下:
正如读者所看到的，我们的DAO只需要继承JpaRepository,它就已经帮我们完成了基本的CURD等操作，如果想了解更多关于spring-data的这个项目，请参考一下spring的官方文档，它比不方案我们对异常的研究。
Service异常设计
ok，终于到了我们的重点了，我们要完成service一些的部分操作:添加收货地址，删除收货地址，获取收货地址列表.
首先看我的service接口定义:
我们来关注一下实现:
添加收货地址
首先再来看一下之前整理的约束条件:
入参:
用户id
收货地址实体信息
约束:
用户id不能为空，且此用户确实是存在的
收货地址的必要字段不能为空
如果用户还没有收货地址，当此收货地址创建时设置成默认收货地址
先看以下代码实现:
其中，已经完成了上述所描述的三点约束条件，当三点约束条件都满足时，才可以进行正常的业务逻辑，否则将抛出异常(一般在此处建议抛出运行时异常-RuntimeException)。
介绍以下以上我所用到的技术:
1、(T t)这个是使用Guava中的进行判断的，因为service中用到的验证较多，所以建议将Preconfitions改成静态导入的方式:
当然Guava的github中的说明也建议我们这样使用。
2、(validator, address)这个使用了hibernate实现的jsr 303规范来做的，需要传入一个validator和一个需要验证的实体,那么validator是如何获取的呢,如下:
他将获取一个Validator对象，然后我们在service中进行注入便可以使用了:
那么BeanValidators这个类是如何实现的？其实实现方式很简单，只要去判断jsr 303的标注注解就ok了。
那么jsr 303的注解写在哪里了呢？当然是写在address实体类中了: