JAX-RS client: ResponseProcessingException movimentazione

Question

Alcuni metodi di richiesta di chiamata di overload, come ad esempio: get() e post(Entity<?> entity) (ce ne sono altri) di SyncInvoker ritorno un oggetto Response, piuttosto che il contenuto deserializzati.

ho notato che nel caso di get(), non v'è alcuna documentata ResponseProcessingException, mentre altri metodi, come ad esempio tutti i 3 sovraccarico post metodi, possono gettare un ResponseProcessingException.

mi rendo conto che è un ResponseProcessingExceptionRuntimeException che eredita da ProcessingException, ma ho ancora sarebbe interpretare questo per significare che il metodo get() non gettare un ResponseProcessingException.

È corretto? Che mi dici di ClientResponseFilter? Perché il comportamento è diverso dal comportamento degli altri metodi di richiesta di chiamata (put, post, ..)?

Inoltre, Javadoc per i metodi che fanno gettare un ResponseProcessingException dice:

in caso di lavorazione di una risposta HTTP ricevuta fallisce (ad esempio in un filtro o durante la conversione dei dati dell'entità risposta ad un istanza di un particolare tipo di Java ).

La parte:

o durante la conversione dei dati dell'entità risposta a un'istanza di un tipo particolare Java

sembra essere sbagliato qui, come il metodo readEntity non dovrebbe tuttavia sono stati chiamati:

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

Si tratta di una copia & errore di documentazione della pasta?

Immagino che un filtro sarebbe un caso valido, però.

Answer 1

La documentazione è sicuramente incoerente. È chiaro che lo ResponseProcessingException deve essere generato quando un errore ClientResponseFilter non riesce.

L'implementazione sto guardando (RESTEasy 3.0.16) fa questo:

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

Non v'è alcuna ragione che il metodo get non dichiarare l'eccezione quando le put e post metodi fanno. Internamente sono tutti gestiti dallo stesso codice.

La mia conclusione è che la leggera differenza nella documentazione tra i metodi è solo una svista.

È interessante notare che, nella mia copia del codice sorgente, il metodo get() ha questa linea nel suo javadoc:

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

Mentre tutti gli altri metodi simili (ad esempio get(Class<T>)) sono documentati in questo modo:

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

Ciò che attira l'attenzione è il nome completo della classe nel primo. Solo un sospetto, ma questo mi fa pensare che sia stato fatto in un momento diverso o da una persona diversa. Forse sto sovraanalizzando. Ho cercato di esaminare la cronologia delle revisioni, ma tutto ciò che ho trovato era un singolo commit che diceva "sposta il codice sorgente nel proprio repository"). Così tanto per quello.

Tuttavia, come hai sottolineato, non si tratta di un errore, dal momento che ResponseProcessingException è e una sottoclasse di ProcessingException e non è nemmeno un'eccezione controllata.

Answer 2

Se non si desidera che l'eccezione sia racchiusa in ResponseProcessingException, è possibile estendere la propria eccezione, quindi arriverà senza avvolgere. Naturalmente, ciò è fattibile solo se si utilizza la propria eccezione e se si è soddisfatti con RuntimeException.