在 REST 端点上有一个 throws 子句是否被认为是糟糕的设计？ [复制]答案

【问题标题】：Is having a throws clause on a REST endpoint considered a poor design? [duplicate]在 REST 端点上有一个 throws 子句是否被认为是糟糕的设计？ [复制]
【发布时间】：2015-09-22 04:21:04
【问题描述】：

我想从我的 REST 端点抛出异常。但是，我对好的 REST 设计技术不太熟悉。考虑以下...

//note the throws clause
@POST
public Response saveNewActivity(@HeaderParam("sessionTokenString") String sessionTokenString, Activity activity) throws Exception {
    Activity result = as.saveNewActivity(activity);
    if (result == null) {
        throw new DuplicateDataException("blah blah blah");
    }
    return Response.ok(result).build();
}

与处理异常并仅显式返回响应相比

@POST
public Response saveNewActivity(@HeaderParam("sessionTokenString") String sessionTokenString, Activity activity) {
    try {
        Activity result = as.saveNewActivity(activity);
        if (result == null) {
            throw new DuplicateDataException("blah blah blah");
        }
        return Response.ok(result).build();
    } catch (Exception e) {
         return Response.status(Response.Status.SOME_STATUS).build();
    }
}

我可以使用 ExceptionMapper 映射 DuplicateDataException，如下所示

public class DuplicateDataExceptionMapper implements ExceptionMapper<DuplicateDataException> {

    @Override
    public Response toResponse(DuplicateDataException e) {
        ErrorMessage errorMessage = new ErrorMessage ("Activity names must be unique.", <HttpStatusNumber>, "<add documentation here>");
        return Response.status(Status.NOT_FOUND).entity(errorMessage).build();
    }
}

尽管最终还是会返回一个响应，但是处理异常（无论它们是否是 RuntimeExceptions）的一种方式是否优于另一种方式，或者这真的不重要吗？我从未在 REST 端点上看到过 throws 语句，这就是我问的原因。

请注意 this question 或 this question 没有给出我正在寻找的答案。

【问题讨论】：

ExceptionMapper exists for a reason, it is the idiomatic way to handle exceptions so use it. 任何关于将异常作为好/坏设计的意见都只是意见，尤其是因为处理所有异常的特定方式来自服务电话的提供ExceptionMapper。

标签： java rest

【解决方案1】：

如果父类捕获抛出的异常并返回适当的 HTTP 响应错误代码 (4xx)，则初始代码正常。

如果没有父类捕获这些以使它们成为 4xx 而不是 500，那么您的代码 - 将响应代码更改为适合此特定错误的代码 - 似乎是一个非常好的主意。

【讨论】：

如果您要投反对票并投票删除，您能否在评论中解释原因？
我没有给你投反对票。事实上，我对你投了赞成票。
有人对我投了反对票，我一直在摸索为什么；给点赞的两位，非常感谢！ :)

【解决方案2】：

通过异常是个坏主意。

从客户端的角度来看，它会导致一个 http 500 错误代码，不会告诉任何自动程序。

您应该设计您的代码以尝试拦截所有可能的错误，并在您的有效响应中使用适当的错误代码进行回复。如果您在 json 中的回复类似于以下内容：

{
    statusCode: 345,
    errorMessage: 'The error code message'
}

将 http 状态码 500 留给意外错误。

【讨论】：