bien le bonjour je souhaiterai avoir votre avis sur l'utilisation du try catch dans un developpement?
on m'a dit que c'était une chose merveilleuse mais je souhaiterai avoir l'avis aiguisé de développeurs de renommé.
merci d'avance ++
bien le bonjour je souhaiterai avoir votre avis sur l'utilisation du try catch dans un developpement?
on m'a dit que c'était une chose merveilleuse mais je souhaiterai avoir l'avis aiguisé de développeurs de renommé.
merci d'avance ++
une recherche sur n'a jamais tué personne !!!!
Le try catch est une structure tres utile qui te permet de tester un bout de code et si ce traitement gènère une erreure, tu l'a recupère pour faire un autre traitement.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8 try { //ton code } catch (une exception pour quelquechose de précis, ou toutes les exceptions) { le traitement à faire si tu attrape une execption. }
Plus généralement tu t'apercevras que le try catch est impératif pour tout ce qui touche aux entrées / sorties, de toute sorte : accès fichier, accès bdd, nouveau process, etc. Bref, tout ce dont tu ne peux pas être 100% sur de son état.
Pour ce qui est à l'intérieur, tu n'es pas censé en avoir car tu te dois de le maitriser (On ne va pas mettre de NullReferenceException partout -_-)
Les Entrées utilisateurs n'ont pas besoin de try catch, tu dois pouvoir vérifier ses entrées automatiquement et ne pas attendre d'erreur (par exemple utiliser TryParse() que Parse() pour les valeurs, etc. )
Tu dois éviter au maximum d'intercepter "volontairement" une exception. ex : tu n'attends pas que l'exception FileNotFoundException se déclenches : tu tests d'abord l'existence du fichier, et ensuite tu encapsules le traitement dans un try catch, ou evidemment tu interceptes quand même l'exception : car évidemment entre le test d'existence et le traitement, le fichier peut disparaitre : c'est à ce moment que l'exception devient "imprévisible"
L'exception est donc là pour gérer un cas inattendu / imprévisible.
Donc, rare sont les programmes sans try catch
C'est une partie assez complexe la gestion des exceptions, et ca demande de l'expérience. Et comme ca prend du temps face au impératif du moment, c'est souvent baclé...
Je ne pense pas tout gérer convenablement, mais je sais que je fais bien plus attention qu'il y a quelques mois
ce bout de code pourra, je l'espere, t'aider a comprendre :
sans ce try catch, le code se serait planté!
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11
12 int a = 15; int b = 0; try { int c = a/b; // b vaut 0 (division impossible) } catch(DivideByZeroException) { // recuperation de l'erreur MessageBox.Show("Impossible de diviser par zéro"); }
Pas très long pourtant un try catch.C'est une partie assez complexe la gestion des exceptions, et ca demande de l'expérience. Et comme ca prend du temps face au impératif du moment, c'est souvent baclé...
Perso j'attrape les exceptions et je les met dans un fichier log.
Après plus qu'à gérer l'instabilité potentielle qui pourrait survenir sur l'application. En fait cela reviens à classer les exceptions en deux cas :
- Les fatals -> on arrête l'appli et on libères les ressources.
- Les autres -> l'appli peut fonctionner, mais on coupe certaine fonctionnalité.
Dans les deux cas il faut prévoir un système d'alerte pour informer de l'état du programme.
Si tu test que b est différent de 0 avant de faier la division, tu n'as aps de plantage.
Et avoir 0 pour b c'est quelque chose à quoi tu peux t'attendre.
Un meilleur exemple :
Finally t'assure que quoi qu'il se passe, le code qui est dans finally sera exécuté.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28 if (!Directory.Exist("c:\\temp")) { Directory.CreateDirectory("c:\\temp"); } Try { StreamReader sr = File.CreateText("c:\\temp\\toto.txt"); sr.WriteLine("blabla"); sr.Flush(); sr.close(); if(File.Exist("c:\\temp\\toto.txt")) { File.Move("c:\\temp\\toto.txt", "c:\\temp2\\titi.txt"); } } Catch(FileNotFoundException) { //Fait ce que tu dois faire !!!! } Catch(DirectoryNotFoundException) { //Fait ce que tu dois faire !!!! } Finally { //Le code indipensable à faire, et que tu veux être sur qu'il soit fait }
Non, placer un Trycatch, c'est facile.
Mais Gérer CONVENABLEMENT des exceptions, c'est + long + compliqué.
-Il ne faut pas simplement "catch( Exception exc )" mais préciser quelle exception pour quel context et quel traitement pour chacune
-Le bloc "finally" n'est pas si évident à maitriser au début, un novice ne peut pas penser à tout.
-Il faut pouvoir logguer les exceptions majeures et les renvoyer automatiquement à l'équipe de dèv
-Le cas échéant il est intéressant "d'enrichir" une exception
Un trycatch c'est pas long, mais faire du boulot propre avec les exceptions, c'est comme le reste : ca demande de l'expérience et du temps.
J'estime moi même que ne gère pas parfaitement mes exceptions...
J'attendais avec impatience le "best pratice" dans "Contribuer", j'ai pas rezieuté si il y avait du nouveau d'ailleurs
D'ailleurs on a oublié d'aborder un point :
Où attraper les exceptions ?
En effet, tu peux décider de catcher une exception localement sur le code qui présente un risque comme dans nos exemples.
Mais tu peux très bien décider de gérer l'exception plus haut, par exemple au niveau de l'appelle de la méthode qui pose un risque potentielle.
Le choix se fait normalement au niveau de la conception, et il ya des choses intéressante dans les deux cas.
Tu attrape l'exception au niveau du code qui présente un risque :
Bah tu peux la gérer la traiter, et faire en sorte de poursuivre le déroulement de la méthode courante.
Genre tu tentes le déplacement d'un fichier, mais cela échoue, mais ce déplacement n'est pas primordiale pour le programme mais faire le reste de la méthode si.
Tu attrape l'exception au niveau de l'appelant de la méthode :
Normalement dès que l'exceptio est levée dans la méthode, le reste du code n'est pas effectué, et cela remonte directement à l'appelant.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8 Try { MonObjet.MaMethodeAvecRisque(); } Catch(FileNotFoundException) { }
C'est le cas où si une exception se produit, surtout ne pas faire le reste du code car cela risque de rendre instable l'application. Vaut mieux revenir à l'appelant et faire comme si on ne pouvait pas appeler la méthode !!!
Pour expliquer, il faut commencer par le plus bas niveau!
je me trompe???
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager