如何设计出优雅的Java异常？

//============ 以下为约束条件 ==============

//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": "找不到该用户"

}