Клиент JAX-RS: обработка ResponseProcessingException

Некоторые перегруженные методы запроса вызова, такие как: get() и post(Entity<?> entity) (есть другие) SyncInvoker return a Response, а не немаршаризованный контент.

Я заметил, что в случае get() не зарегистрировано ResponseProcessingException, в то время как другие методы, такие как все 3 перегруженные методы post, могут вызывать ResponseProcessingException.

Я знаю, что ResponseProcessingException является RuntimeException, который наследует от ProcessingException, но я все же буду понимать это как означающий что метод get() не будет выбрасывать ResponseProcessingException.

Это правильно? Что относительно ClientResponseFilter? Почему поведение отличается от поведения других методов запроса вызова (put, post,...)?

Кроме того, Javadoc для методов, которые бросают ResponseProcessingException, говорит:

в случае сбоя обработки полученного HTTP-ответа (например, в фильтре или во время преобразования данных объекта ответа в экземпляр конкретный тип Java).

Часть:

или во время преобразования данных объекта ответа в экземпляр конкретный тип Java

кажется неправильным здесь, поскольку метод readEntity еще не был вызван:

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

Это ошибка копирования и вставки документации?

Я думаю, что фильтр был бы корректным.

ОТВЕТЫ

Ответ 1

Документация, безусловно, несовместима. Понятно, что ResponseProcessingException предполагается выбросить, когда не удалось выполнить ClientResponseFilter.

Реализация, на которую я смотрю (RESTEasy 3.0.16), делает следующее:

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

Нет причин, чтобы метод get не объявлял исключение, если методы put и post. Внутри они все обрабатываются одним и тем же кодом.

Мое заключение заключается в том, что небольшая разница в документации между этими методами - это просто недосмотр.

Интересно, что в моей копии исходного кода метод get() имеет эту строку в своем javadoc:

/**
 * @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.

Что бросается в глаза - это полное имя класса в первом. Просто догадка, но это заставляет меня думать, что это было введено в другое время или другим человеком. Может быть, я переусердствую. Я попытался просмотреть историю изменений, но все, что я нашел, было одним фиксатором, говорящим "переместить исходный код в свой собственный репозиторий" ). Так много для этого.

Однако, как вы указали, это не ошибка, так как ResponseProcessingException есть и подкласс ProcessingException и даже не является проверенным исключением.

Ответ 2

Если вы не хотите, чтобы ваше исключение было обернуто в ResponseProcessingException, вы можете сделать это исключение, но оно не будет завершено. Конечно, это возможно, только если вы используете свое собственное исключение, и вы в порядке с RuntimeException.