provare sempre a intercettare chiamate di risorse esterne?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

> Sapere quando impostare un blocco try / catch. Ad esempio, è possibile verificare a livello di programmazione una condizione che potrebbe verificarsi senza utilizzare la gestione delle eccezioni. In altre situazioni, è opportuno utilizzare la gestione delle eccezioni per rilevare una condizione di errore.

Questo è quello che ho trovato e ha senso per me .. Controlla manualmente le cose ovvie, lascia che try-catch faccia il resto ..

Answer 4

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.

Answer 5

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.

Answer 6

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.