java - 其余异常: Wrappers vs Error Object

Question

假设我们有一个休息服务定义为:

    @GET
    @Produces("application/json")
    public Response getAllCategories(@QueryParam(value="startIndex") int startIndex, @QueryParam(value="size") int size)
    {

        logger.info("[SampleCategoryController][getAllCategories]");

        List<YpCategory> categoryList = sampleCategoryService.getAllCategories(startIndex, size);       
        return Response.ok(categoryList).build();       
    }

服务定义为:

public class SampleCategoriesServiceImpl {

    public List<YpCategory> getAllCategories(int startIndex, int size) {
        ...
        //call some method that throws a runtime exception
        ...

    }
}

以及应用程序异常处理程序:

@Provider
@Component
public class ApplicationExceptionHandler implements ExceptionMapper<Throwable> {

    @Override
    public Response toResponse(Throwable ex) {  
            String internalError = "There was a problem processing your request.";
            return Response.serverError().entity(new ExceptionResponse(500, internalError)).build();
        }
    }

 }

异常响应对象:让异常冒泡到ApplicationExceptionHandler并返回ExceptionResponse对象。这种方式看起来更干净，因为服务不必尝试处理它无法真正执行任何操作的异常，并且客户端仍然会收到 json 响应。

响应包装器:类别对象将扩展某种类型的通用响应包装器对象，其中包含有关错误代码的信息，然后我总是必须包装可以在 try/catch 中抛出运行时异常的方法 block 并在 catch block 中设置错误代码和消息信息。

这些方式中的一种是首选吗？使用这些方法之一来处理错误有缺点吗？

Answer 1

我认为在这种情况下你应该使用ExceptionMapper。让异常在实现之外进行处理会更干净。此外，您的实现应该尽可能少地了解 HTTP。您的实现对框架其他部分的了解越少，它就会变得越灵活。

举个例子。假设将来支持非 HTTP 协议(protocol)，并且错误消息传递将与使用 HTTP 状态代码不同。您可以在 ExceptionMapper 级别进行实现，而无需更改您的实现。否则，您必须重构您的应用程序以了解非 HTTP 协议(protocol)。

需要明确的是，我并不是说现在有其他可用的实现。这只是一个理论。