Quando è vuota una clausola catch [duplicato]

Question

Quando è vuota una clausola catch [duplicato]

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

1

Ho visto molte domande e spiegazioni relative alle clausole di cattura vuote, ma non sono mai stato realmente sicuro di cosa significhi "vuoto".

Una clausola di cattura come questa è vuota? Chiaramente non è vuoto per l'occhio perché c'è una riga di codice. Ma il problema non è davvero gestito. Invece l'errore è appena registrato.

try {
    // do some work
} catch (SomeException e) {
    logger.error("Some error", e);
}

Lo vedo abbastanza spesso perché ci sono molte eccezioni in cui non puoi fare qualcosa a riguardo se fallisce. La conseguenza è che l'errore non è completamente ingerito ma almeno registrato.

Quindi la domanda è: è questo codice errato se "fai semplicemente" loggare l'errore e non fare nulla?

java exceptions

posta Playerwtf 22.07.2013 - 10:32

fonte

3 risposte

2

Suppongo che dipenda se l'eccezione è selezionata o è un'eccezione di runtime.

L'idea alla base delle eccezioni controllate (quelle che devi "catturare") è che si tratta di errori da cui l'applicazione può recuperare. Quindi, quando catturati, dovresti idealmente fornire una logica per recuperare da queste eccezioni. Sebbene tu possa ricondurli sulla gerarchia della chiamata, è meglio gestirli il più rapidamente possibile ( non lasciare mai che i tuoi clienti facciano ciò che puoi fare per i tuoi clienti ).

Le eccezioni di runtime, d'altra parte, normalmente non sono recuperabili. Lasciano l'applicazione in cattivo stato. Più spesso che no, l'unico modo per gestire queste eccezioni è quello di registrare quante più informazioni per facilitare le indagini. Le applicazioni tipiche avrebbero un blocco "catch-all" per gestire tutte le eccezioni del runtime.

risposta data 22.07.2013 - 11:15

fonte

0

Penso che si dovrebbe sostenere che non sarà spesso buon codice - è piuttosto meglio che inghiottire completamente l'errore (o almeno è meglio che farlo senza una spiegazione chiara).

Il problema di base è che nello stesso modo in cui il codice non getta mai, nella mia esperienza nessuno guarderà i log a meno che non ci sia un problema (o fino a quando il problema nascosto non viene scoperto con altri mezzi). Parlo per esperienza pratica in quanto ho codice non dissimile da quanto sopra.

Detto questo se stai catturando e inghiottendo un'eccezione specifica (come implica il codice) e spieghi perché lo stai facendo, allora potrebbe essere perfettamente ragionevole.

Ciò che non è ragionevole è un generico catch-all che lo fa - perché poi stai entrando in conseguenze impreviste, cioè mentre inghiottirà il banale errore non critico che è lì per affrontarlo, ingerirà anche lo show-stopper questo sta danneggiando delicatamente i tuoi dati ...

risposta data 22.07.2013 - 11:01

fonte

Leggi altre domande sui tag java exceptions

Pattern di progettazione di fabbrica - ottenere i tipi da un tavolo Prima di sviluppare un'applicazione web, di quante specifiche hai bisogno? [chiuso]

score 5 · Accepted Answer

Questo è un catch vuoto:

 catch (SomeException e) {
 }

È una cattiva idea molto , perché ignori silenziosamente l'eccezione. E anche se è la vera intenzione, allora dovresti avere almeno un commento in là per dire al futuro-tu (o qualsiasi altro sviluppatore) perché dovrebbe essere vuoto.

Probabilmente, questo è ancora vuoto:

 catch (SomeException e) {
   // nothing to do because we frobnicated the foo before
 }

Ma almeno questa volta sappiamo che alcuni pensieri sono andati in esso e l'autore ha pensato che un blocco catch-nulla è corretto qui.

Tutto ciò che aggiunge la registrazione o altra gestione delle eccezioni non è "vuoto" in alcun modo significativo.

Indipendentemente dal fatto che qualche codice di manipolazione / registrazione sia sufficiente in un dato luogo, è una domanda completamente diversa: a volte semplicemente registrare l'eccezione è la cosa giusta, altre volte devono essere prese misure più drastiche.