MethodA chiama un MethodB che a sua volta chiama MethodC.

Non esiste una gestione delle eccezioni in MethodB o MethodC. Ma c'è una gestione delle eccezioni in MethodA.

In MethodC si verifica un'eccezione.

Ora, quell'eccezione sta ribollendo fino a MethodA, che la gestisce in modo appropriato.

Cosa c'è di sbagliato in questo?

Nella mia mente, a un certo punto un chiamante eseguirà MethodB o MethodC, e quando si verificano eccezioni in quei metodi, ciò che si otterrà dalla gestione delle eccezioni all'interno di quei metodi, che essenzialmente è solo un blocco try / catch / finally invece di lasciare semplicemente si gonfiano fino alla chiamata?

L'affermazione o il consenso sulla gestione delle eccezioni è quando l'esecuzione non può continuare proprio per questo - un'eccezione. Capisco quello. Ma perché non catturare l'eccezione più in alto della catena invece di provare / catturare i blocchi fino in fondo.

Lo capisco quando devi liberare risorse. Questa è una questione completamente diversa.

Come principio generale, non prendere eccezioni a meno che tu non sappia cosa farne. Se MethodC genera un'eccezione, ma MethodB non ha un modo utile per gestirla, dovrebbe consentire all'eccezione di propagarsi fino a MethodA.

Le uniche ragioni per cui un metodo dovrebbe avere un meccanismo di cattura e riprogrammazione sono:

• Si desidera convertire un'eccezione in un'altra diversa che sia più significativa per il chiamante sopra.
• Vuoi aggiungere ulteriori informazioni all'eccezione.
• È necessaria una clausola di cattura per ripulire le risorse che sarebbero trapelate senza una.

Altrimenti, la cattura di eccezioni al livello sbagliato tende a provocare un codice che fallisce silenziosamente senza fornire alcun feedback utile al codice chiamante (e in definitiva all'utente del software). L'alternativa di catturare un'eccezione e poi riproporla immediatamente è inutile.

Cosa c'è di sbagliato in questo?

Assolutamente niente.

Ora, quell'eccezione sta ribollendo fino a MethodA, che la gestisce in modo appropriato.

"gestisce in modo appropriato" è la parte importante. Questo è il punto cruciale della gestione delle eccezioni strutturata.

Se il tuo codice può fare qualcosa di "utile" con un'eccezione, provaci. Altrimenti, figuriamoci bene.

. . . perché non catturare l'eccezione più in alto della catena invece di provare / catturare i blocchi fino in fondo.

Questo è esattamente quello che dovresti fare. Se stai leggendo il codice che ha il gestore / i rethrower "fino in fondo", allora [probabilmente] stai leggendo un codice piuttosto scadente.

Purtroppo, alcuni sviluppatori vedono solo i blocchi di cattura come codice "boiler-plate" che inseriscono (nessun gioco di parole inteso) in ogni metodo che scrivono, spesso perché in realtà non "ottengono" la gestione delle eccezioni e pensano di dover aggiungere qualcosa così che le eccezioni non "sfuggono" e uccidono il loro programma.

Parte della difficoltà qui è che, il più delle volte, questo problema non verrà nemmeno notato, perché le Eccezioni non vengono lanciate tutto il tempo ma, quando lo sono , il programma sta per perdere un sacco di tempo e sforzo gradualmente decomprimendo lo stack di chiamate per arrivare da qualche parte che effettivamente fa qualcosa di utile con l'eccezione.

Devi fare la differenza tra Librerie e Applicazioni.

Le biblioteche possono generare liberamente eccezioni non rilevate

Quando progetti una biblioteca, a un certo punto devi pensare a cosa può andare storto. I parametri potrebbero essere nell'intervallo errato o null, le risorse esterne potrebbero non essere disponibili, ecc.

La tua biblioteca il più delle volte non avrà modo di gestirli in modo sensato . L'unica soluzione ragionevole è lanciare un'eccezione appropriata e lasciare che lo sviluppatore dell'applicazione lo gestisca.

Le applicazioni dovrebbero sempre rilevare eccezioni

Quando viene rilevata un'eccezione, mi piace classificarli come errori o errori irreversibili . Un errore regolare significa che una singola operazione all'interno della mia applicazione non è riuscita. Ad esempio, non è stato possibile salvare un documento aperto perché la destinazione non era scrivibile. L'unica cosa sensata da fare per l'applicazione è informare l'utente che l'operazione non può essere completata con successo, fornire informazioni leggibili sull'uomo in merito al problema e quindi lasciare che l'utente decida cosa fare dopo.

Un errore irreversibile è un errore da cui la logica principale dell'applicazione non è in grado di ripristinare. Ad esempio, se il driver del dispositivo grafico si arresta in modo anomalo in un videogioco, l'applicazione non può in alcun modo informare "con grazia" l'utente. In questo caso, dovrebbe essere scritto un file di registro e, se possibile, l'utente dovrebbe essere informato in un modo o nell'altro.

Anche in un caso così grave, l'applicazione dovrebbe gestire questa eccezione in modo significativo. Ciò potrebbe includere la scrittura di un file di registro, l'invio di un rapporto di arresto anomalo, ecc. Non vi è alcun motivo per cui l'applicazione non risponda in qualche modo all'eccezione.

Ciò che è sbagliato nel modello che descrivi è che il metodo A non avrà modo di distinguere tra tre scenari:

1. Il metodo B ha fallito in modo anticipato.

2. Il metodo C fallì in un modo non previsto dal metodo B, ma mentre il metodo B stava eseguendo un'operazione che poteva essere tranquillamente abbandonata.

3. Il metodo C fallì in un modo non previsto dal metodo B, ma mentre il metodo B stava eseguendo un'operazione che poneva le cose in uno stato incoerente presumibilmente temporaneo che B non riusciva a ripulire a causa del fallimento di C.

L'unico modo in cui il metodo A sarà in grado di distinguere tali scenari sarà se l'eccezione generata da B include informazioni sufficienti a tale scopo o se lo stack che si svolge per il metodo B fa sì che l'oggetto venga lasciato in uno stato esplicitamente invalidato . Sfortunatamente, la maggior parte dei framework delle eccezioni rende entrambi i modelli imbarazzanti, costringendo i programmatori a prendere decisioni di progettazione "male minore".