Ho letto in molti posti incluso questo - link - che dovresti usare la gestione delle eccezioni quando qualcosa è veramente eccezionale.
La funzione .Net File.Open genera FileNotFoundException, ecc. invece di restituire i codici di errore. Ora può capitare frequentemente che il nome del file passato non esista. Questa non mi sembra una situazione davvero eccezionale.
Perché può essere la ragione per cui File.Open non segue le best practice di gestione delle eccezioni?
Ci si aspetta che chiami File.Open(...) solo sui file che sai (o prevedi) di esistere. Se non sai se il percorso file passato esiste o meno, devi chiamare File.Exists(...) prima di provare ad aprirlo.
Se provi ad aprire un file che prevedi di esistere, ma non lo fa, si tratta di un'eccezione.
Il modo in cui le eccezioni vengono gestite in .NET è materialmente diverso dal modo in cui vengono gestite, per esempio, Java. Le eccezioni in Java richiedono di più dal programmatore rispetto a .NET, quindi l'argomento potrebbe essere quello di riservare la gestione delle eccezioni in Java per i casi veramente eccezionali.
In .NET, una condizione eccezionale è quella che non è possibile recuperare in modo ragionevole senza l'intervento dell'utente. Se l'utente passa il nome di un file a un metodo che si aspetta che il file esista, ma il file non esiste, si tratta di una condizione eccezionale.
Come programmatore, hai ancora la possibilità di controllare prima l'esistenza del file, prima di chiamare il metodo che lo richiede.
In ogni caso, la guida offerta da Microsoft sembra relativamente semplice:
If the event is truly exceptional and is an error (such as an unexpected end-of-file), using exception handling is better because less code is executed in the normal case. If the event happens routinely, using the programmatic method to check for errors is better.
Leggi altre domande sui tag exceptions exception-handling