Perché la cattura (eccezione) è quasi sempre una cattiva idea?

Question

Perché la catch(Exception) è quasi sempre una cattiva idea?

Answer 1

Perché quando rilevi l'eccezione devi gestirlo correttamente. E non puoi aspettarti di gestire tutti i tipi di eccezioni nel tuo codice. Inoltre, quando rilevi tutte le eccezioni, puoi ottenere un'eccezione che non può gestire e impedire che il codice sia in cima allo stack per gestirlo correttamente.

Il principio generale è catturare il tipo più specifico possibile.

Answer 2

Perché non si sa davvero perché si è verificata un'eccezione e diverse eccezioni richiedono che un'auto molto speciale venga gestita correttamente (se possibile), come ad esempio OutOfMemoryException e simili eccezioni di sistema di basso livello.

Pertanto, si deve solo rilevare le eccezioni:

• che si sa esattamente come trattare con esso (ad esempio FileNotFoundException o giù di lì)
• quando si re-raise in seguito (ad esempio per effettuare il post cleanup -fail)
• quando è necessario trasportare l'eccezione di un altro thread

Answer 3

dipende da quello che vi serve. Se è necessario gestire diversi tipi di eccezioni in modi diversi, è necessario utilizzare più blocchi catch e catturare tutte le eccezioni specifiche possibili.

Ma a volte potrebbe essere necessario gestire tutte le eccezioni allo stesso modo. In questi casi, catch (Exception) potrebbe essere ok. Ad esempio:

try 
    { 
     DoSomething(); 
    } 
    catch (Exception e) 
    { 
     LogError(e); 
     ShowErrorMessage(e); // Show "unexpected error ocurred" error message for user. 
    } 

Answer 4

È necessario rilevare eccezioni solo se è possibile gestirle correttamente. Dato che non puoi gestire correttamente tutte le possibili eccezioni, non dovresti prenderle :-)

Answer 5

Breve storia: si chiama bug masking. Se hai un pezzo di codice che non funziona bene e genera eccezioni (o passi input malformati a quel pezzo di codice) e accechi solo gli occhi catturando tutte le possibili eccezioni, in realtà non scoprirai mai il bug e lo sistemerai.

Answer 6

Questo può essere specifica Java:

A volte è necessario chiamare i metodi che gettano eccezioni controllate. Se questo è nel livello EJB/business logic hai 2 scelte: prendile o rilancia.

La rilevazione di classi di eccezioni specifiche implica la necessità di analizzare nuovamente le azioni per le quali è possibile generare eccezioni quando si cerca di vedere come questo codice gestisce le eccezioni. Spesso entrerai in una situazione di "che cosa succede se ..." e può essere molto impegnativo lavorare solo se le eccezioni vengono gestite correttamente.

Rilanciare significa che il codice che chiama il tuo EJB sarà pieno di codice che in genere non significa nulla per la classe chiamante. N.B. lanciando eccezioni controllate dai metodi EJB significa che sei responsabile del ripristino manuale delle transazioni.

Answer 7

Oltre a ciò che ancora risposto da @anthares:

Perché quando si cattura un'eccezione si suppone di gestire in modo corretto. E non puoi aspettarti di gestire tutti i tipi di eccezioni nel tuo codice. Inoltre, quando rilevi tutte le eccezioni, puoi ottenere un'eccezione che non può gestire e impedire che il codice sia in cima allo stack per gestirlo correttamente.

Il principio generale è catturare il tipo più specifico possibile.

catch(Exception) è una cattiva pratica perché cattura anche tutti i RuntimeException (eccezione non controllata).

Answer 8

Ma a volte è OK! Come se avessi un pezzo di codice che fa qualcosa di "extra", di cui non ti interessa davvero, e non vuoi che faccia esplodere la tua applicazione. Ad esempio, recentemente ho lavorato a una grande applicazione in cui i nostri partner commerciali desideravano che una determinata transazione giornaliera venisse riepilogata in un nuovo file di registro. Hanno spiegato che il registro non era tanto importante per loro, e che non era qualificato come requisito. Era solo qualcosa in più che li avrebbe aiutati a dare un senso ai dati elaborati. Non ne avevano bisogno, perché potevano ottenere le informazioni altrove. Quindi questo è un caso raro in cui è perfettamente corretto catturare e ingoiare le eccezioni.

Ho lavorato anche in un'azienda in cui sono stati catturati tutti i Throwables e quindi ripubblicato all'interno di una RuntimeException personalizzata. Non consiglierei questo approccio, ma solo sottolineando che è stato fatto.

Answer 9

Trovo due usi accettabili di cattura (eccezione): - Al livello più alto dell'applicazione (appena prima di tornare all'utente). In questo modo puoi fornire un messaggio adeguato. - Usalo per mascherare le eccezioni di basso livello a quelle aziendali.

Il primo caso è auto-esplicativo, ma mi permetta di sviluppare il secondo:

fare:

try { 
    xxxx 
} catch(Exception e) { 
    logger.error("Error XXX",e) 
} 

è bug mascheramento come @dimitarvp detto.

Ma

try { 
    xxxx 
} catch(Exception e) { 
    throw new BussinessException("Error doing operation XXX",e) 
} 

E 'una cosa diversa. In questo modo non stai ignorando bug e nascondendo sotto il tappeto. Stai fornendo un'eccezione di alto livello con un messaggio più esplicativo a livelli di applicazione più elevati.

E 'sempre importante anche due riescono eccezione al suo corretto livello. Se si lascia escalare un'eccezione di basso livello a un livello aziendale elevato è praticamente impossibile che il livello superiore possa gestirlo bene. In quei casi, preferisco mascherare i bassi livelli di eccezioni con un business quello che fornisce un contesto e il messaggio meglio e che ha anche l'eccezione originale di essere in grado di andare ai dettagli.

Anche così, se è possibile ottenere eccezioni più concrete e si può fornire un trattamento migliore per loro è necessario farlo.

Se in un blocco di codice è possibile ottenere SQLException e NetworkException, è necessario catturarli e fornire messaggi e trattamenti adeguati per ciascuno di essi. Ma se alla fine del blocco try/catch hai un'eccezione che la mappa con un BussinessException va bene per me. In effetti, ritengo adeguato che i livelli di servizio più elevati generino solo eccezioni aziendali (con dettagli all'interno).