Discussion :

[shyx21]

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 ++

[smyley]

http://jlambert.developpez.com/tutor...escsharp/#Ltry

[ced600]

une recherche sur n'a jamais tué personne !!!!

[jonathanC]

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.
}

[Chubyone]

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

[fally]

ce bout de code pourra, je l'espere, t'aider a comprendre :

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");
}

sans ce try catch, le code se serait planté!

[ced600]

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é...

Pas très long pourtant un try catch.
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.

[ced600]

ce bout de code pourra, je l'espere, t'aider a comprendre :

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");
}

sans ce try catch, le code se serait planté!

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 :

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
}

Finally t'assure que quoi qu'il se passe, le code qui est dans finally sera exécuté.

[Chubyone]

Pas très long pourtant un try catch.

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

[ced600]

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 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
Try
{
   MonObjet.MaMethodeAvecRisque();
}
Catch(FileNotFoundException)
{
}

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.
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 !!!

[fally]

Pour expliquer, il faut commencer par le plus bas niveau!
je me trompe???

[Chubyone]

Pour expliquer, il faut commencer par le plus bas niveau!
je me trompe???

Bien sur que non mais exposer des notions plus complexes élève la curiosité : et donc l'intéret de faire "mieux", plus vite

C'était de simples remarques /conseils auquel il/elle pourra penser plus tard, lorsqu'il/elle aura déjà maitrisé les bases.

[shyx21]

une recherche sur n'a jamais tué personne !!!!

simpa ta remarque...............
sinon merci pour ceux qui on répondu de manière constructive
je comprend ainsi mieux l'utilisation qui doit en etre fait.
au fait Chubyone c'est il.
merci a vous ++

[smyley]

?

[ced600]

simpa ta remarque...............

Merci, il n'y a aucun problème, j'aime bien rappeler certaine évidence, surtout à ceux qui les oublis