Perché l'eccezione HttpClientErrorException di Spring è un'eccezione non controllata?

Question

Perché l'eccezione HttpClientErrorException di Spring è un'eccezione non controllata?

#1 da (3 voti)
#2 da (0 voti)

1

Oracle riepiloga lo scopo delle eccezioni non controllate come:

The next question might be: "If it's so good to document a method's API, including the exceptions it can throw, why not specify runtime exceptions too?" Runtime exceptions represent problems that are the result of a programming problem, and as such, the API client code cannot reasonably be expected to recover from them or to handle them in any way. Such problems include arithmetic exceptions, such as dividing by zero; pointer exceptions, such as trying to access an object through a null reference; and indexing exceptions, such as attempting to access an array element through an index that is too large or too small.

Ok, le eccezioni non controllate sono per eventuali errori causati dall'errore del programmatore. Sicuro.

Spring documentazione per HttpClientErrorException (che estende RuntimeException) dice che l'eccezione è per:

Exception thrown when an HTTP 4xx is received.

Non riesco a vedere che si tratta di un'eccezione di "errore del programmatore".

Nello scenario che sto testando, sto facendo una query a Spring RestTemplate, ma il server su cui si sta interrogando potrebbe essere inattivo e restituire un 404. Questo sembra uno stato di cose perfettamente normale, non un errore di programmazione .

Forse sto interagendo in modo errato con il Framework di primavera (ad esempio dovrei rilevare 404 prima di usare RestTemplate?) o c'è qualcos'altro che non sto considerando?

java exceptions spring

posta dwjohnston 26.04.2016 - 02:39

fonte

2 risposte

Leggi altre domande sui tag java exceptions spring

Java 8 Opzionale in JavaScript Se un repository o il servizio Login / Register hanno un servizio di crittografia come dipendenza?

score 3 · Answer 1

Penso che tu stia bene.

Guardalo da questo punto di vista. Eccezioni non controllate - Polemica .

If a client can reasonably be expected to recover from an exception, make it a checked exception. If a client cannot do anything to recover from the exception, make it an unchecked exception.

È un handicap dovuto alla premessa di cui sopra. Il client Spring Rest non si aspetta di riprendersi da un 404 , quindi sfrutta la decisione di rilevare e gestire l'errore nei livelli superiori. È responsabilità del sistema decidere cosa fare quando le connessioni ai servizi esterni terminano con errori 4xx o 5xx. Il modo per non compromettere l'intero sito Web di Spring e l'architettura core con inutile try/catch/final blocks e refactoring innumerevoli componenti aggiungendo il throw alla firma del loro metodo, è digitare errori che non dovrebbero gestire come RuntimeExceptions .

Di conseguenza, l'utente Spring è coinvolto in tale eventualità. La primavera ci ha delegato a prendersi cura e a recuperare da tale errore, o lasciarlo andare (come fanno) fino ai livelli successivi ... E così via ...

Alla tua domanda

ie. Should I be detecting the 404 before using the RestTemplate?

Dipende se puoi recuperare te stesso da tale errore. Puoi? C'è qualcosa da fare quando il servizio esterno non è disponibile? Se questo è il caso, vorrei prendere HttpClientErrorException . In caso contrario, probabilmente lo prenderei comunque per poterlo loggare e (forse) avvolgere in un'eccezione di servizio o di business solo per fornire al cliente maggiori informazioni sul fallimento della sua richiesta. Dove è successo, perché è successo, cosa fare, ecc. .

Indipendentemente da ciò che fanno gli altri , Spring ci consente di gestire gli errori di risposta in modo aggraziato attraverso ErrorHandlers . O per sovrascrivere il metodo handleResponse

score 0 · Answer 2

Suppongo che Spring considerasse 404 uno scenario "irrecuperabile" .

Credo che il concetto di "recupero da un 404" non sia in linea con ciò che Oracle intendeva con "recuperabile" .

"irrecuperabile" di Oracle significa che la merda è andata seriamente male. Come in NullPointerException o simile. Come in un bug nel codice sorgente. Ecco dove entrano in gioco le eccezioni non controllate.

La mia comprensione è che tutti i codici HTTP sono considerati uno scenario valido delle specifiche HTTP. Sono documentati, previsti e noti come attenuanti.

Ho paura che Spring sia dalla parte sbagliata di questo.

Ad esempio RestTemplate # doExecute, avvolge l'eccezione controllata del client http in un'eccezione non controllata. Questo è male ...

Attualmente sto affrontando un problema molto simile.

Ho bisogno di scrivere un ResponseErrorHandler personalizzato che genera alcune eccezioni molto specifiche (che potrebbero estendere IOException, perché è nella firma dell'interfaccia).

Quindi RestTemplate nasconde questo avvolgendo IOException in un'eccezione non controllata.

Sarebbe bello da Spring dare una spiegazione, o se non ce n'è, aggiustalo.