java - from - Cliente JAX-RS: manejo de ResponseProcessingException

web service client netbeans wsdl

Question

Algunos métodos de solicitud de llamada sobrecargados, como: get() y post(Entity<?> entity) (hay otros) de SyncInvoker devuelven un objeto Response , en lugar del contenido no marcado.

Observé que en el caso de get() , no hay ResponseProcessingException documentada, mientras que otros métodos, como los 3 métodos de post sobrecargados, pueden arrojar ResponseProcessingException .

Soy consciente de que ResponseProcessingException es una RuntimeException que hereda de ProcessingException , pero aún interpreto que esto significa que el método get() no emitirá ResponseProcessingException .

¿Es esto correcto? ¿Qué pasa con ClientResponseFilter ? ¿Por qué el comportamiento es diferente del comportamiento de los otros métodos de solicitud de llamada ( put , post , ...)?

Además, el Javadoc para los métodos que lanzan ResponseProcessingException dice:

en caso de que el procesamiento de una respuesta HTTP recibida falle (por ejemplo, en un filtro o durante la conversión de los datos de la entidad de respuesta a una instancia de un tipo de Java particular).

La parte:

o durante la conversión de los datos de la entidad de respuesta a una instancia de un tipo de Java particular

parece estar mal aquí, ya que el método readEntity aún no debería haberse llamado:

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

¿Es esto un error de documentación de copiar y pegar?

Supongo que un filtro sería un caso válido, sin embargo.

Answer 1

La documentación es ciertamente inconsistente. Está claro que ResponseProcessingException está destinado a lanzarse cuando falla un ClientResponseFilter .

La implementación que estoy viendo (RESTEasy 3.0.16) hace esto:

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

No hay ninguna razón para que el método get no declare la excepción cuando lo hacen los métodos de put y post . Internamente, todos son manejados por el mismo código.

Mi conclusión es que la pequeña diferencia en la documentación entre los métodos es solo un descuido.

Curiosamente, en mi copia del código fuente, el método get() tiene esta línea en su javadoc:

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

Si bien todos los otros métodos similares (por ejemplo, get(Class<T>) ) están documentados de esta manera:

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

Lo que llama mi atención es el nombre completo de la clase en el primero. Solo una corazonada, pero eso me hace pensar que fue presentada en otro momento o por otra persona. Tal vez estoy sobrealizando. Traté de ver el historial de revisión, pero todo lo que encontré fue una única confirmación diciendo "mover el código fuente a su propio repositorio"). Demasiado para eso.

Sin embargo, como señaló, no es un error, ya que ResponseProcessingException es una subclase de ProcessingException y, de todos modos, ni siquiera es una excepción comprobada.

Answer 2

Si no desea que su excepción se ajuste a ResponseProcessingException , puede hacer que su excepción se extienda, luego vendrá sin envolver. Por supuesto, esto es factible solo si usa su propia excepción y está bien con RuntimeException.