ok,上边是一个模型关系，用户-收货地址的关系是1-n的关系。上边的@Data是使用了一个叫做lombok的工具，它自动生成了Setter和Getter等方法，用起来非常方便，感兴趣的读者可以自行了解一下。
正如读者所看到的，我们的DAO只需要继承JpaRepository,它就已经帮我们完成了基本的CURD等操作，如果想了解更多关于spring-data的这个项目，请参考一下spring的官方文档，它比不方案我们对异常的研究。
ok，终于到了我们的重点了，我们要完成service一些的部分操作:添加收货地址，删除收货地址，获取收货地址列表.
listAddresses(Integer uid);}
我们来关注一下实现:
添加收货地址
首先再来看一下之前整理的约束条件:
入参:
用户id
收货地址实体信息
约束:
用户id不能为空，且此用户确实是存在的
收货地址的必要字段不能为空
如果用户还没有收货地址，当此收货地址创建时设置成默认收货地址
先看以下代码实现:
@Override
public Address createAddress(Integer uid, Address address) {
//============ 以下为约束条件 ==============
//1.用户id不能为空，且此用户确实是存在的
Preconditions.checkNotNull(uid);
User user = userDao.findOne(uid);
if(null == user){
throw new RuntimeException("找不到当前用户!");
}
//2.收货地址的必要字段不能为空
BeanValidators.validateWithException(validator, address);
//3.如果用户还没有收货地址，当此收货地址创建时设置成默认收货地址
if(ObjectUtils.isEmpty(user.getAddresses())){
address.setIsDefault(true);
}
//============ 以下为正常执行的业务逻辑 ==============
address.setUser(user);
Address result = addressDao.save(address);
return result;
}
其中，已经完成了上述所描述的三点约束条件，当三点约束条件都满足时，才可以进行正常的业务逻辑，否则将抛出异常(一般在此处建议抛出运行时异常-RuntimeException)。
介绍以下以上我所用到的技术:
Preconfitions.checkNotNull(T t)这个是使用Guava中的com.google.common.base.Preconditions进行判断的，因为service中用到的验证较多，所以建议将Preconfitions改成静态导入的方式:
1import static com.google.common.base.Preconditions.checkNotNull;
当然Guava的github中的说明也建议我们这样使用。
BeanValidators.validateWithException(validator, address);
这个使用了hibernate实现的jsr 303规范来做的，需要传入一个validator和一个需要验证的实体,那么validator是如何获取的呢,如下:
@Configuration
public class BeanConfigs {
@Bean
public javax.validation.Validator getValidator(){
return new LocalValidatorFactoryBean();
}
}
他将获取一个Validator对象，然后我们在service中进行注入便可以使用了:
@Autowired
private Validator validator ;
那么BeanValidators这个类是如何实现的？其实实现方式很简单，只要去判断jsr 303的标注注解就ok了。
那么jsr 303的注解写在哪里了呢？当然是写在address实体类中了:
@Entity
@Setter
@Getter
public class Address {
@Id
@GeneratedValue
private Integer id;
@NotNull
private String province;//省
@NotNull
private String city;//市
@NotNull
private String county;//区
private Boolean isDefault = false;//是否是默认地址
@ManyToOne(cascade={CascadeType.ALL})
@JoinColumn(name="uid")
private User user;
}
写好你需要的约束条件来进行判断，如果合理的话，才可以进行业务操作，从而对数据库进行操作。
这块的验证是必须的，一个最主要的原因是:这样的验证可以避免脏数据的插入。如果读者有正式上线的经验的话，就可以理解这样的一个事情，任何的代码错误都可以容忍和修改，但是如果出现了脏数据问题，那么它有可能是一个毁灭性的灾难。程序的问题可以修改，但是脏数据的出现有可能无法恢复。所以这就是为什么在service中一定要判断好约束条件，再进行业务逻辑操作的原因了。
此处的判断为业务逻辑判断，是从业务角度来进行筛选判断的，除此之外，有可能在很多场景中都会有不同的业务条件约束，只需要按照要求来做就好。
对于约束条件的总结如下:
基本判断约束(null值等基本判断)
实体属性约束(满足jsr 303等基础判断)
业务条件约束(需求提出的不同的业务约束)
当这个三点都满足时，才可以进行下一步操作
ok,基本介绍了如何做一个基础的判断，那么再回到异常的设计问题上，上述代码已经很清楚的描述如何在适当的位置合理的判断一个异常了，那么如何合理的抛出异常呢？
只抛出RuntimeException就算是优雅的抛出异常吗？当然不是，对于service中的抛出异常，笔者认为大致有两种抛出的方法:
抛出带状态码RumtimeException异常
抛出指定类型的RuntimeException异常
相对这两种异常的方式进行结束，第一种异常指的是我所有的异常都抛RuntimeException异常，但是需要带一个状态码，调用者可以根据状态码再去查询究竟service抛出了一个什么样的异常。
第二种异常是指在service中抛出什么样的异常就自定义一个指定的异常错误，然后在进行抛出异常。
一般来讲，如果系统没有别的特殊需求的时候，在开发设计中，建议使用第二种方式。但是比如说像基础判断的异常，就可以完全使用guava给我们提供的类库进行操作。jsr 303异常也可以使用自己封装好的异常判断类进行操作，因为这两种异常都是属于基础判断，不需要为它们指定特殊的异常。但是对于第三点义务条件约束判断抛出的异常，就需要抛出指定类型的异常了。
对于
1throw new RuntimeException("找不到当前用户!");
定义一个特定的异常类来进行这个义务异常的判断:
public class NotFindUserException extends RuntimeException {
public NotFindUserException() {
super("找不到此用户");
}
public NotFindUserException(String message) {
super(message);
}
}
然后将此处改为:
1throw new NotFindUserException("找不到当前用户!");
or
1throw new NotFindUserException();
ok,通过以上对service层的修改，代码更改如下:
@Override
public Address createAddress(Integer uid, Address address) {
//============ 以下为约束条件 ==============
//1.用户id不能为空，且此用户确实是存在的
checkNotNull(uid);
User user = userDao.findOne(uid);
if(null == user){
throw new NotFindUserException("找不到当前用户!");
}
//2.收货地址的必要字段不能为空
BeanValidators.validateWithException(validator, address);
//3.如果用户还没有收货地址，当此收货地址创建时设置成默认收货地址
if(ObjectUtils.isEmpty(user.getAddresses())){
address.setIsDefault(true);
}
//============ 以下为正常执行的业务逻辑 ==============
address.setUser(user);
Address result = addressDao.save(address);
return result;
}
这样的service就看起来稳定性和理解性就比较强了。
删除收货地址:
入参:
用户id
收货地址id
约束:
用户id不能为空，且此用户确实是存在的
收货地址不能为空，且此收货地址确实是存在的
判断此收货地址是否是用户的收货地址
判断此收货地址是否为默认收货地址，如果是默认收货地址，那么不能进行删除
它与上述添加收货地址类似，故不再赘述，delete的service设计如下:@Override
public void deleteAddress(Integer uid, Integer aid) {
//============ 以下为约束条件 ==============
//1.用户id不能为空，且此用户确实是存在的
checkNotNull(uid);
User user = userDao.findOne(uid);
if(null == user){
throw new NotFindUserException();
}
//2.收货地址不能为空，且此收货地址确实是存在的
checkNotNull(aid);
Address address = addressDao.findOne(aid);
if(null == address){
throw new NotFindAddressException();
}
//3.判断此收货地址是否是用户的收货地址
if(!address.getUser().equals(user)){
throw new NotMatchUserAddressException();
}
//4.判断此收货地址是否为默认收货地址，如果是默认收货地址，那么不能进行删除
if(address.getIsDefault()){
throw new DefaultAddressNotDeleteException();
}
//============ 以下为正常执行的业务逻辑 ==============
addressDao.delete(address);
}
设计了相关的四个异常类:NotFindUserException,NotFindAddressException,NotMatchUserAddressException,DefaultAddressNotDeleteException.根据不同的业务需求抛出不同的异常。
获取收货地址列表:
入参:
用户id
约束:
用户id不能为空，且此用户确实是存在的
代码如下:@Override
public List
listAddresses(Integer uid) {//============ 以下为约束条件 ==============
//1.用户id不能为空，且此用户确实是存在的
checkNotNull(uid);
User user = userDao.findOne(uid);
if(null == user){
throw new NotFindUserException();
}
//============ 以下为正常执行的业务逻辑 ==============
User result = userDao.findOne(uid);
return result.getAddresses();
}
api异常设计
大致有两种抛出的方法:
抛出带状态码RumtimeException异常
抛出指定类型的RuntimeException异常
这个是在设计service层异常时提到的，通过对service层的介绍，我们在service层抛出异常时选择了第二种抛出的方式，不同的是，在api层抛出异常我们需要使用这两种方式进行抛出:要指定api异常的类型，并且要指定相关的状态码，然后才将异常抛出，这种异常设计的核心是让调用api的使用者更能清楚的了解发生异常的详细信息，除了抛出异常外，我们还需要将状态码对应的异常详细信息以及异常有可能发生的问题制作成一个对应的表展示给用户，方便用户的查询。（如github提供的api文档，微信提供的api文档等）,还有一个好处:如果用户需要自定义提示消息，可以根据返回的状态码进行提示的修改。
api验证约束
首先对于api的设计来说，需要存在一个dto对象，这个对象负责和调用者进行数据的沟通和传递，然后dto->domain在传给service进行操作，这一点一定要注意，第二点，除了说道的service需要进行基础判断(null判断)和jsr 303验证以外，同样的，api层也需要进行相关的验证，如果验证不通过的话，直接返回给调用者，告知调用失败，不应该带着不合法的数据再进行对service的访问，那么读者可能会有些迷惑，不是service已经进行验证了，为什么api层还需要进行验证么？这里便设计到了一个概念:编程中的墨菲定律，如果api层的数据验证疏忽了，那么有可能不合法数据就带到了service层，进而讲脏数据保存到了数据库。
所以缜密编程的核心是:永远不要相信收到的数据是合法的。
api异常设计
设计api层异常时，正如我们上边所说的，需要提供错误码和错误信息，那么可以这样设计，提供一个通用的api超类异常，其他不同的api异常都继承自这个超类:
public class ApiException extends RuntimeException {
protected Long errorCode ;
protected Object data ;
public ApiException(Long errorCode,String message,Object data,Throwable e){
super(message,e);
this.errorCode = errorCode ;
this.data = data ;
}
public ApiException(Long errorCode,String message,Object data){
this(errorCode,message,data,null);
}
public ApiException(Long errorCode,String message){
this(errorCode,message,null,null);
}
public ApiException(String message,Throwable e){
this(null,message,null,e);
}
public ApiException(){
}
public ApiException(Throwable e){
super(e);
}
public Long getErrorCode() {
return errorCode;
}
public void setErrorCode(Long errorCode) {
this.errorCode = errorCode;
}
public Object getData() {
return data;
}
public void setData(Object data) {
this.data = data;
}
}
然后分别定义api层异常：ApiDefaultAddressNotDeleteException,ApiNotFindAddressException,ApiNotFindUserException,ApiNotMatchUserAddressException。
以默认地址不能删除为例:
public class ApiDefaultAddressNotDeleteException extends ApiException {
public ApiDefaultAddressNotDeleteException(String message) {
super(AddressErrorCode.DefaultAddressNotDeleteErrorCode, message, null);
}
}
AddressErrorCode.DefaultAddressNotDeleteErrorCode就是需要提供给调用者的错误码。错误码类如下:
public abstract class AddressErrorCode {
public static final Long DefaultAddressNotDeleteErrorCode = 10001L;//默认地址不能删除
public static final Long NotFindAddressErrorCode = 10002L;//找不到此收货地址
public static final Long NotFindUserErrorCode = 10003L;//找不到此用户
public static final Long NotMatchUserAddressErrorCode = 10004L;//用户与收货地址不匹配
}
ok,那么api层的异常就已经设计完了，在此多说一句，AddressErrorCode错误码类存放了可能出现的错误码，更合理的做法是把他放到配置文件中进行管理。
api处理异常
api层会调用service层，然后来处理service中出现的所有异常，首先，需要保证一点，一定要让api层非常轻，基本上做成一个转发的功能就好(接口参数，传递给service参数，返回给调用者数据,这三个基本功能)，然后就要在传递给service参数的那个方法调用上进行异常处理。
此处仅以添加地址为例:
@Autowired
private IAddressService addressService;
/**
* 添加收货地址
* @param addressDTO
* @return
*/
@RequestMapping(method = RequestMethod.POST)
public AddressDTO add(@Valid @RequestBody AddressDTO addressDTO){
Address address = new Address();
BeanUtils.copyProperties(addressDTO,address);
Address result;
try {
result = addressService.createAddress(addressDTO.getUid(), address);
}catch (NotFindUserException e){
throw new ApiNotFindUserException("找不到该用户");
}catch (Exception e){//未知错误
throw new ApiException(e);
}
AddressDTO resultDTO = new AddressDTO();
BeanUtils.copyProperties(result,resultDTO);
resultDTO.setUid(result.getUser().getId());
return resultDTO;
}
这里的处理方案是调用service时，判断异常的类型，然后将任何service异常都转化成api异常，然后抛出api异常，这是常用的一种异常转化方式。相似删除收货地址和获取收货地址也类似这样处理，在此，不在赘述。
api异常转化
已经讲解了如何抛出异常和何如将service异常转化为api异常，那么转化成api异常直接抛出是否就完成了异常处理呢？ 答案是否定的，当抛出api异常后，我们需要把api异常返回的数据(json or xml)让用户看懂，那么需要把api异常转化成dto对象(ErrorDTO),看如下代码:
@ControllerAdvice(annotations = RestController.class)
class ApiExceptionHandlerAdvice {
/**
* Handle exceptions thrown by handlers.
*/
@ExceptionHandler(value = Exception.class)
@ResponseBody
public ResponseEntity exception(Exception exception,HttpServletResponse response) {
ErrorDTO errorDTO = new ErrorDTO();
if(exception instanceof ApiException){//api异常
ApiException apiException = (ApiException)exception;
errorDTO.setErrorCode(apiException.getErrorCode());
}else{//未知异常
errorDTO.setErrorCode(0L);
}
errorDTO.setTip(exception.getMessage());
ResponseEntity responseEntity = new ResponseEntity<>(errorDTO,HttpStatus.valueOf(response.getStatus()));
return responseEntity;
}
@Setter
@Getter
class ErrorDTO{
private Long errorCode;
private String tip;
}
}
ok,这样就完成了api异常转化成用户可以读懂的DTO对象了，代码中用到了@ControllerAdvice，这是spring MVC提供的一个特殊的切面处理。
当调用api接口发生异常时，用户也可以收到正常的数据格式了,比如当没有用户(uid为2)时，却为这个用户添加收货地址,postman(Google plugin 用于模拟http请求)之后的数据:
{
"errorCode": 10003,
"tip": "找不到该用户"
}
关于“怎么优雅的设计Java异常”这篇文章的内容就介绍到这里，感谢各位的阅读！相信大家对“怎么优雅的设计Java异常”知识都有一定的了解，大家如果还想学习更多知识，欢迎关注创新互联行业资讯频道。
当前名称：怎么优雅的设计Java异常
分享网址：http://cdkjz.cn/article/pjccpi.html
