JAX-RS 客户端：响应处理异常处理

java jakarta-ee jax-rs jersey java-ee-7

2022-09-02 11:01:00

一些重载的调用请求方法，如 SyncInvoker 的：和（还有其他方法）返回一个对象，而不是未编组的内容。get()post(Entity<?> entity)Response

我注意到，在get（）的情况下，没有记录的RectionProcessingException，而其他方法，例如所有3个重载的post方法，可能会抛出一个.ResponseProcessingException

我知道这是一个从ProcessingException继承的，但我仍然会解释为意味着该方法不会抛出.ResponseProcessingExceptionRuntimeExceptionget()ResponseProcessingException

这是正确的吗？ClientResponseFilter 呢？为什么行为与其他调用请求方法（put、post,..）的行为不同？

此外，对于确实抛出的方法的Javadoc说：ResponseProcessingException

在处理收到的HTTP响应失败时（例如，在过滤器中或在将响应实体数据转换为特定Java类型的实例期间）。

部分：

或在将响应实体数据转换为特定 Java 类型的实例期间

这里似乎是错误的，因为该方法不应该被调用：readEntity

https://jersey.java.net/documentation/latest/filters-and-interceptors.html#d0e9915

这是复制和粘贴文档错误吗？

不过，我想过滤器将是一个有效的情况。

答案 1

文档肯定不一致。很明显，这是为了在失败时被抛出。ResponseProcessingExceptionClientResponseFilter

我正在查看的实现（RESTEasy 3.0.16）是这样做的：

try {
    filter.filter(requestContext, responseContext);
} catch (ResponseProcessingException e) {
    throw e;
} catch (Throwable e) {
    throw new ResponseProcessingException(response, e);
}

当 and 方法声明异常时，没有理由不声明异常。在内部，它们都由相同的代码处理。getputpost

我的结论是，这些方法之间在文档上的细微差异只是一个疏忽。

有趣的是，在我的源代码副本中，该方法在其javadoc中有以下行：get()

/**
 * @throws javax.ws.rs.ProcessingException
 *          in case the invocation processing has failed.

而所有其他类似的方法（例如）都记录如下：get(Class<T>)

/**
 * @throws ProcessingException         in case the request processing or subsequent I/O operation fails.

吸引我眼球的是第一个类名中的完全限定的类名。只是一种预感，但这让我觉得它是在不同的时间或由不同的人放进去的。也许我过度分析了。我试图查看修订历史记录，但我发现的只是一个提交，上面写着“将源代码移动到它自己的存储库”）。太多了。

但是，正如您所指出的，这不是一个错误，因为 is 和的子类，甚至不是一个已检查的异常。ResponseProcessingExceptionProcessingException

答案 2

如果你不希望你的异常被包装进去，你可以让你的异常扩展它，那么它将不换行。当然，这只有在您使用自己的异常并且可以使用 RuntimeException 时才可行。ResponseProcessingException