1.什么时候抛出异常?
如果你觉得某些”问题”解决不了了，那么你就可以抛出异常了。比如，你在写一个service,其中在写到某段代码处,你发现可能会产生问题，那么就请抛出异常吧，相信我，你此时抛出异常将是一个最佳时机
2.抛出怎么样的异常?
异常的抛出不仅仅是throw掉或者catch掉,而也应该进行异常的业务逻辑的处理所以本身也可以看做if--else的这样的一种分支进行处理掉
传统的项目都是以MVC框架为基础进行开发的，本文主要从使用restful风格接口的设计来体验一下异常处理的优雅。
我们把关注点放在restful的api层(和web中的controller层类似)和service层，研究一下在service中如何抛出异常，然后api层如何进行捕获并且转化异常。
使用的技术是:spring-boot,jpa(hibernate),mysql,
1.对于入参参数的判断:
有两个重要的工具类
- Guava中的Preconditions类实现了很多入参方法的判断
- jsr 303的validation规范(目前实现比较全的是hibernate实现的hibernate-validator)
- 如果使用了这两种推荐技术，那么入参的判断会变得简单很多。推荐大家多使用这些成熟的技术和jar工具包，他可以减少很多不必要的工作量。我们只需要把重心放到业务逻辑上。而不会因为这些入参的判断耽误更多的时间
2.我们经常说的模型其实就是指的是实体模型,由实体模型之间的关系构成了整个逻辑之间的关系,而这个实体模型之间的关系其实也是数据库数据之间的关系.所以这个就是模型的概念
根据项目场景来看，需要两个domain模型，一个是用户实体，一个是地址实体
对于约束条件的总结如下:
- 基本判断约束(null值等基本判断)
- 实体属性约束(满足jsr 303等基础判断)
- 业务条件约束(需求提出的不同的业务约束)
-
对于service中的抛出异常，笔者认为大致有两种抛出的方法:
- 抛出带状态码RumtimeException异常
- 抛出指定类型的RuntimeException异
api异常设计
大致有两种抛出的方法:
- 抛出带状态码RumtimeException异常
- 抛出指定类型的RuntimeException异常
- 这个是在设计service层异常时提到的，通过对service层的介绍，我们在service层抛出异常时选择了第二种抛出的方式，不同的是，在api层抛出异常我们需要使用这两种方式进行抛出:要指定api异常的类型，并且要指定相关的状态码，然后才将异常抛出，这种异常设计的核心是让调用api的使用者更能清楚的了解发生异常的详细信息，除了抛出异常外，我们还需要将状态码对应的异常详细信息以及异常有可能发生的问题制作成一个对应的表展示给用户，方便用户的查询。（如github提供的api文档，微信提供的api文档等）,还有一个好处:如果用户需要自定义提示消息，可以根据返回的状态码进行提示的修改。
- 设计api层异常时，正如我们上边所说的，需要提供错误码和错误信息，那么可以这样设计，提供一个通用的api超类异常，其他不同的api异常都继承自这个超类:
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
