provare sempre a intercettare chiamate di risorse esterne?
Domanda
Devo sempre racchiudere le chiamate di risorse esterne in un try-catch? (ad es. chiamate a un database o file system) Esiste una procedura ottimale per la gestione degli errori quando si chiamano risorse esterne?
Soluzione
Cattura solo eccezioni che puoi gestire . Ad esempio, quando si utilizzano risorse esterne, la migliore pratica è quella di individuare specifiche eccezioni che si sa che è possibile gestire. Nel caso di file questo può essere (IOException, SecurityException, ecc.), Nel caso di Database l'eccezione può essere SqlException o altri.
In ogni caso, non intercettare le eccezioni che non gestisci , lascia che fluiscano verso un livello superiore che può. Oppure, se per qualche motivo si rilevano delle eccezioni ma non le si gestisce, riprovarle usando solo lancio; (che creerà un rilancio dell'operazione IL, invece di lanciare).
Nel caso in cui si utilizzino risorse che non si conoscono il tipo di eccezioni che si potrebbero generare, si è costretti a catturare il tipo di eccezione generale. E in questo caso la cosa più sicura sarebbe usare tali risorse da un dominio app diverso (se possibile) o lasciare che l'eccezione salga al livello più alto (ex UI) dove possono essere visualizzati o registrati.
Altri suggerimenti
Penso che ci siano tre ragioni per avere un blocco catch:
- Puoi gestire l'eccezione e ripristinarla (dal "codice di basso livello")
- Desideri reimballare l'eccezione (di nuovo, dal codice "basso livello")
- Sei in cima allo stack e anche se non riesci a ripristinare l'operazione stessa, non vuoi che l'intera app si interrompa
Se ti attieni a questi, dovresti avere pochissimi blocchi catch rispetto ai blocchi try / finally
e quei blocchi try / finally
chiamano quasi sempre Dispose
, e quindi meglio scritto come usando
.
In conclusione: è molto importante avere un blocco finalmente
per liberare risorse, ma i blocchi catch
dovrebbero essere di solito più rari.
Questo è quello che ho trovato e ha senso per me .. Controlla manualmente le cose ovvie, lascia che try-catch faccia il resto ..
Eric Lippert ha un buon blog su questo, qui .
Non ha senso (tranne che per "infastidire" (vedi blog)) prendere un'eccezione a meno che tu non possa fare qualcosa di utile; e nella maggior parte dei casi semplicemente non puoi - quindi lascialo in bolla (la tua UI dovrebbe ovviamente pulire e mostrare qualcosa).
Tuttavia, potresti avere un " try / finally " per gestire la gestione delle risorse. O anche più pulito, un "uso" di " bloccare per fare lo stesso.
Penso che la risposta assoluta sia completamente condizionata (come hai il controllo sull'ambiente, qual è l'equilibrio atteso tra prestazioni e coerenza e molti altri ne sono sicuro), ma in generale lo faccio sempre, scegliendo la sicurezza rispetto le prestazioni potenzialmente più lente.
dipende sempre da ciò che vuoi ottenere. Un server che non risponde potrebbe essere abbastanza serio da interrompere tutto ciò che la routine sta facendo e l'eccezione dovrebbe essere lanciata al chiamante.
In altri casi, non ti importa se non hai aggiornato il db o meno. Quindi consumare l'eccezione è OK.
Ovviamente, non vuoi mostrare la traccia dello stack al tuo utente finale, quindi dovrai prenderla da qualche parte.