jersey框架统一处理异常机制

最近在整理jersey异常的统一处理，结合官网的解释，jersey一般支持两种异常的处理：

1、WebApplicationException异常的子类

@Override
public Response getResponse() {
return Response.status(httpStatus).type(MediaType.APPLICATION_JSON).entity(getResultInfo()).build();
}

重写此方法后，框架直接返回结果

2、实现ExceptionMapper接口

@Override
public Response toResponse(Exception exception) {
String result = "";
ResultInfo resultInfo = new ResultInfo();
resultInfo.setCode(RestfulConstant.RESULT_STATUS_NOT_FOUND);
resultInfo.setMessage(RestfulConstant.RESULT_MESSAGE_ERROR_NOT_FOUND);
result = JSONObject.fromObject(resultInfo).toString();
// return Response.status(Response.Status.NOT_FOUND).entity(new
// ErrorResponse(exception.getClass().toString(),
// exception.getMessage())).build();
System.err.println("我调用过SystemExceptionMapper");
return Response.status(Response.Status.NOT_FOUND).entity(result).build();
}

现在就是要分析一下，这两个情况的组合：

一、如果只使用第一种来处理异常，比较简单，但是不是很灵活，因为你如果想要根据自己的业务去自定义异常，同时为了避免过多的try catch语句块，这种方式有点不是很好

二、如果使用第二种来处理异常，此时可以实现多个ExceptionMapper的类统一处理异常，如

1、

@Provider

public class BadMethodExceptionMapper implements ExceptionMapper<NotAllowedException> {}

2、

@Provider

public class SystemExceptionMapper implements ExceptionMapper<Exception>{}

但是，这样会碰到多种情况，咱们一一来分析

（1）、如果是我们自定义并且是手动抛出的异常，如 throw new NotAllowedException(Response.status(200).entity("xixixi").build());此时被捕捉处理的Mapper是上面的2

（2）、如果是系统的抛出的异常，如我们使用postman来人为的改动请求方法，将get改成put，此时捕捉异常处理的是1

（3）、如果将上面的1 Mapper实现给删除掉，也就是只有2的Mapper实现，则（1）（2）中的捕捉异常处理的是2

三、如果第一种和第二种异常处理同时存在，如果我们显示的抛出WebApplicationException异常的子类，第二种Mapper不能够捕捉这个异常，它将会直接返回，特别注意的就是此时发生这种情况是因为WebApplicationException异常的子类构建过Reponse实体，所以不会被Mapper来捕捉

所以，如果想要用统一异常处理最好只需要调用一个public class SystemExceptionMapper implements ExceptionMapper<Exception>{}来处理，免得出现不同的结果。