La source suivante est relativement simple (a destination de ceux qui commencent en c#), mais j'ai jugé utile de la poster car ce que j'ai vu sur le site n'est pas forcément complet sur certains points.
- La gestion des exceptions :
La source "http://csharpfr.com/codes/TRY-CATCH-FINALLY_11382.aspx" met en avant comment gérer des exceptions, mais plusieurs points peuvent être précisés : - Ce qui n'est pas dit, c'est que l'on peut faire plusieurs catch dans un try. Il faut cependant penser à les organiser du plus précis au plus générique. Ici, on a la gestion des erreurs pour l'ouverture d'un fichier. FileNotFoundException dérive de IOException, qui dérive de la classe Exception. Donc FileNotFoundException est plus "précis" que Exception, et doit être mis en premier, car une fois que l'on est passé dans un catch, on passe directement au finally. Si le catch Exception était avant le catch FileNotFoundException, en cas de fichier non présent sur le disque, on passerais dans le catch exception, puis dans le finally, sans passer dans le catch FileNotFoundException.
Note : On passe toujours dans le finally, qu'il y ait une exception levée ou non. - Il n'est pas non plus nécessaire de déclarer une variable contenant l'exception. Ici, vous avez deux catch. Pour le FileNotFoundException, on ne déclare pas de variable pour stocker l'erreur. Par contre, on en déclare une dans le catch Exception (le catch générique, en quelque sorte), de sorte que l'on puisse afficher le problème.
- Vous pouvez utiliser la propriété StackTrace de l'exception qui a été levée. Celle-ci vous permet de voir quels appels de méthodes ont été effectués avant que le plantage survienne. cela peut-être bien pratique en débuggage.
- La lecture d'un fichier
La source "http://csharpfr.com/codes/LECTURE-ECRITURE-DANS-FICHIER_11558.aspx" explique comment lire un fichier, mais ne gère pas les exceptions. Un test est fait pour savoir si le fichier que l'on tente de lire existe, mais même si le fichier existe, on est jamais assuré de pouvoir le lire (problème de droits, problème de verrouillage par windows, problème de lecture matériel, ...). Je vous propose donc une méthode de lecture de fichier que je considère plus propre (à mon humble avis), car gérant mieux les problèmes.
Note : Le FileStream est déclaré avant le try pour une question de portée de variables. Si je déclare mon FileStream dans le bloc try, c'est à dire entre le "try{" et le "}catch", alors mon FileStream ne sera pas accessible pour la fermeture du fichier, dans le finally. La portée de la variable ne s'étendrait qu'au try (mais pas aux catch, ni au finally).
De plus, si l'ouverture du fichier échoue, le constructeur de FileStream retourne null. Dans le finally, nous somme donc obligés de valider un point, si fs vaut null c'est qu'il y a eu un problème, et donc on ne ferme pas le flux du fichier. Dans le cas inverse, on ferme les vannes. - Les directives de pré compilation
J'en profite pour vous coller un petit #if DEBUG... Celui-ci permet de savoir si la variable de pré compilation nommée DEBUG est déclarée. Elle l'est si l'IDE est en mode debug. Lors de la distribution de la version "Release" de l'application, DEBUG ne fera plus partie des variables de pré compilation, ce qui veut dire qu'en cas d'erreur en mode release, on affiche pas le stack trace dans le messagebox.
Le code en question :
FileStream fs = null ;
try {
fs = new FileStream ( "c:\\monFichier.txt" , FileMode . Open );
StreamReader reader = new StreamReader ( fs );
string contenuFichier = reader . ReadToEnd ();
MessageBox . Show ( contenuFichier );
} catch ( FileNotFoundException ){
MessageBox . Show ( "Le fichier que vous avez tenté d'ouvrir n'existe pas" );
} catch ( Exception ex ){
string erreur = "Une erreur est survenue lors de l'ouverture du fichier\n" + ex . Message ;
#if DEBUG
erreur += "\n\n" + ex . StackTrace ;
#endif
MessageBox . Show ( erreur );
} finally {
if ( fs != null ) fs . Close ();
}