Discussion :

[abelman]

Salut,

Il y a un truc que je me suis toujours demandé sur les try catch sans jamais trouver une réponse convaincante...

En quoi il n'est pas bien de faire ceci (Mettre un seul catch qui attrape toutes les exceptions)??

Code :

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

1
2
3
4
5
6
7
8
try
{
    // mon code
}
catch(Exception ex)
{
    throw new CMonExceptionPerso("Mon message", ex);
}

Apparement il est conseillé de faire plutot ceci (Mettre un catch pour chque exception envisageable)

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
try
{
    // mon code
}
catch(ArgumentException ex)
{
    throw new CMonExceptionPerso("Mon message", ex);
}
catch(ArgumentNullException ex)
{
    throw new CMonExceptionPerso("Mon message", ex);
}
catch(IndexOutOfRangeException ex)
{
    throw new CMonExceptionPerso("Mon message", ex);
}
catch(IOException ex)
{
    throw new CMonExceptionPerso("Mon message", ex);
}

Quelqu'un saurait il pourquoi? Comment vous faites vous sinon?

[neguib]

Bonjour Abelman

J'avoue que je n'utilise pas de la même façon les Exceptions; car pour moi par exemple ma classe dérivée CPersoException est une exception levée par ma classe CPerso suite une verif de type ( if(...) ) avec son message spécifique.
Donc s'il s'agit simplement de formater le message d'exception selon une langue ou autre chose, je vais plutôt créer une méthode type String.Format() ou autre chose qui me renvoie une string à afficher.

Code :

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

1
2
3
4
5
6
7
8
9
10
 
try 
{ // mon code} 
catch(Exception ex) 
{  Console.WriteLine(GetMessage(ex));}
 
//...
 
private string GetMessage(Exception ex)
{ // mon code switch... case ou de localization }

Personnellement je ne connais pas l'intérêt de lever un nouvel objet Exception dans un catch

[del-dongo]

je crois que la question que soulève Abelman ( ), c'est "à quoi ca sert de faire un ou plusieurs catch sur des exceptions spécifiques, plutot que de faire un catch sur la classe de base Exception.

A mon avis tout dépend de la finalité de ton catch, en effet si tu veux simplement que celui ci empeche que ton appli se termine alors un simple

Code :

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

catch(Exception caught)

suffira.

Maintenant la msdn détaille pour chaque appel de méthode les exceptions que celle ci est susceptible de lever. Il est alors interessant de pouvoir spécifier tes catch de facon
1. à identifier quel problème précis il y a eu.
2. à ne pas perdre la sémantique de l'erreur
3. à aiguiller l'utilisateur quand à la résolution de ce problème

pour pousser la méthaphore, il semblerait normal qu'un conducteur puisse avoir recours à un airbag, qu'un skater possède des coudières, et qu'un marin possède un gilet de sauvetage, mais que penser d'un conducteur possédant un airbag, des coudières et un gilet de sauvetage...
C'est lourd et inutile....

[Piotrek]

Personnellement je ne connais pas l'intérêt de lever un nouvel objet Exception dans un catch

Ca te permet de creer une hierarchie d'exceptions(tu remarqueras, il passe l'exception interceptee dans la nouvelle exception) L'interet c'est que tout en haut de la hierarchie tu pourra faire une explication tres detaillle:

Pour un bouton sauvegarde par exemple:
Impossible de sauvgarder vos preferences->Le fichier est en lecture seule->System.IO.IOException

Salut Abelman A mon avis c'est deconseille car:
- Generalement t'as une decision tres claire a prendre en fonction du type d'exception qui arrive
- Eviter de catcher les exceptions trop loin de l'endroit ou elles ont eu lieu
- De faire un traitement specifique de l'erreur en oubliant toutes les autres exceptions possibles qui peuvent arriver
- Pour laisser se propager les exception qu'on n'a pas gere au niveau de l'application, car en gros tu sais pas ce qui s'est passe, tu sais pas si l'etat de ton appli est toujours coherent

[sylk974]

Ceci dit, dans son cas, s'il fait la même chose dans chacun de ses blocs catch, ca a peu d'intérêt de les hiérarchiser.

Mais faire la même chose pour toutes les types d'exception, c'est pas génial non plus.

En fait Abelman, l'erreur n'est pas tellement d'avoir un seul bloc catch dans ton cas, parce que effectivement si tu fais pareil partout, autant avoir qu'un bloc. Mais le problème est justement de gérer toutes tes exceptions de la même manière.

Après selon comment MonExceptionPerso est codé, c'est peut être pas grave.

[Maniak]

:arrow: Salut Abelman :D A mon avis c'est deconseille car:
- Generalement t'as une decision tres claire a prendre en fonction du type d'exception qui arrive
- Eviter de catcher les exceptions trop loin de l'endroit ou elles ont eu lieu
- De faire un traitement specifique de l'erreur en oubliant toutes les autres exceptions possibles qui peuvent arriver
- Pour laisser se propager les exception qu'on n'a pas gere au niveau de l'application, car en gros tu sais pas ce qui s'est passe, tu sais pas si l'etat de ton appli est toujours coherent

Et
- on est censé n'intercepter que les exceptions pour lesquelles on sait quoi faire. ArgumentNullException, je sais pourquoi elle a été lancée et avec quel argument. FileNotFound pareil, je sais ce qui s'est passé, je peux agir en conséquence. Exception... euh... il y a eu... euh... un problème ? :)

[Maniak]

Ceci dit, dans son cas, s'il fait la même chose dans chacun de ses blocs catch, ca a peu d'intérêt de les hiérarchiser.

Sauf pour éviter de masquer des exceptions qui feraient mieux de rester visibles :)
(et on a le droit de faire des méthodes pour regrouper les traitements communs si plusieurs catch sont censés faire la même chose :)

[Piotrek]

A mon avis, le try d'abelman est trop loin de l'endroit ou celles ci peuvent arriver (ya de l'index null et du IO, t'as trop de code dedans!)

[abelman]

Merci déjà d'avoir répondu à tous.
qui a changé mon titre ??

Je me rend compte que mon code en haut pouvais apporter de la confusion. Je met le vrai code en fin de réponse

- neguib, comme l'as indiqué Pio, je lance une exception perso dans le catch pour avoir un max d'information par rapport au contexte. La classe dans laquelle se trouve le code s'appelle CFileCompressor

- del-dongo, tu as bien cerné ma question.

- Maniak:

Exception... euh... il y a eu... euh... un problème ?

Dans ce cas je fais un truc du genre

throw new CMonException("Echec de ma fonction bidule", ex);

Je passe l'exception en inner et dans le code qui catchera CMonException plus haut, j'affiche ex.Message si nécéssaire.

- Pio, Maniak et les autres: Je ne catch pas des exception loin de l'endroit où elle ont lieu. J'ai juste mis un catch pour chaque exception susceptible d'être levée par une des méthodes utilisé dans ma fonction en me servant de la doc MSDN
J'ai commencé à le faire pour justement mettre un message approprié à chaque exception.

Mais alors dans ce cas, je mets quoi comme message pour ArgumentNullException par exemple? Dans le code ci dessous, elle peut être levée par plusieurs instructions différentes et c'est le cas d'autres exception.

Mais je pense finalement que je vais faire des catch pour chque exception spécifique. Si je met juste un catch Exception et que je me retrouve avec un MemoryException ..... ça sert à rien de continuer.

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
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
		public static void CompressFile(string sFileToCompress, string sArchiveFile, ECompressionFormat eFormat, bool bFailOnExistOutFile)
		{
			Stream outCompressedStream = null;
			FileStream inFileStream = null;
			FileStream outFileStream = null;
			FileMode outFileMode;
			byte[] inBuffer;
 
			try
			{
				// Read file to compress
				inFileStream = new FileStream(sFileToCompress, FileMode.Open, FileAccess.Read, FileShare.Read);
				inBuffer = new byte[inFileStream.Length];
				inFileStream.Read(inBuffer, 0, inBuffer.Length);
				// Compression
				if (bFailOnExistOutFile)
					outFileMode = FileMode.CreateNew;
				else
					outFileMode = FileMode.Create;
				outFileStream = new FileStream(sArchiveFile, outFileMode, FileAccess.Write, FileShare.Read);
				if (eFormat == ECompressionFormat.Gzip)
					outCompressedStream = new GZipStream(outFileStream, CompressionMode.Compress);
				else if (eFormat == ECompressionFormat.Deflate)
					outCompressedStream = new DeflateStream(outFileStream, CompressionMode.Compress);
				else
					throw new ArgumentException(Resources.StrCompressInvalidFormat, "eFormat");
				outCompressedStream.Write(inBuffer, 0, inBuffer.Length);
			}
			// catch (ArgumentNullException ex)
			// {
			// }
			// catch (ArgumentOutOfRangeException ex)
			// {
			// }
			// catch (ArgumentException ex)
			// {
			// }
			// catch (FileNotFoundException ex)
			// {
			// }
			// catch (IOException ex)
			// {
			// }
			// catch (System.Security.SecurityException ex)
			// {
			// }
			// catch (DirectoryNotFoundException ex)
			// {
			// }
			// catch (UnauthorizedAccessException ex)
			// {
			// }
			// catch (PathTooLongException ex)
			// {
			// }
 
			catch (Exception ex)
			{
				// Failed to compress file
				throw new CFileCompressorException(String.Format(Resources.StrFCompressFailed, sFileToCompress, sArchiveFile, eFormat), ex);
			}
			finally
			{
				// Close open streams
				if (inFileStream != null)
					inFileStream.Close();
				if (outFileStream != null)
					outFileStream.Close();
				if (outCompressedStream != null)
					outCompressedStream.Close();
			}			
		}

[Piotrek]

Et si c'est trop loin la

tu devrais avoir:
catch, une ligne de code
catch, une ligne de code
catch, une ligne de code
....
et non pas tout catcher a la fin du traitement

Mais alors dans ce cas, je mets quoi comme message pour ArgumentNullException par exemple? Dans le code ci dessous, elle peut être levée par plusieurs instructions différentes et c'est le cas d'autres exception.

en posant le catch pile poil au bon endroit, tu incorpore l'exception ArgumentNullException dans une TapaMisLeNomDuFichierException, tu recatch cette exception de partout ou cette fonction est appellee en la reincorporant dans un PasMoyenDeCOmpresserLesParametresDeLappliException ou un PasPossibleDeCompresserLImageException (en fonction du contexte donc)

Quoique, pour le nom du fichier c'est un mauvais exemple: car tu peux verifier avant (puis envoyer une exception ou mieux gerer ca autrement), donc pas de raison d'etre pour l'exception ArgumentNullException

[abelman]

Et si c'est trop loin la

tu devrais avoir:
catch, une ligne de code
catch, une ligne de code
catch, une ligne de code
....
et non pas tout catcher a la fin du traitement

Euh ... Je vais pas mettre un try catch à chaque ligne de code quand même ... Sinon j'arrête la prog

[Piotrek]

<ModeTrollBleu>
Ok j'ai un bon compromis pour pas que t'arretes:

Tu cree une classe qui s'ocupe de gerer la gestion de compression, tu mets chaque ligne dans une fonction, chaque parametre dans une propriete, donc effectivement: tu ne fera pas un catch par ligne mais catch par fonction
</ModeTrollBleu>


(Je suis aussi confronte a ce genre pbs et idem, je gere ca sans me prendre la tete. Preuve que la POO c'est vraiement pas la panacee question methode de programmation, vivement la POO 2.0)
(c'est pas moi qui ait modifie ton titre)

[Maniak]

- Maniak:

Exception... euh... il y a eu... euh... un problème ? :)

Dans ce cas je fais un truc du genre

throw new CMonException("Echec de ma fonction bidule", ex);

Je passe l'exception en inner et dans le code qui catchera CMonException plus haut, j'affiche ex.Message si nécéssaire.

Donc tu ne prends en compte que le message, donc forcément, Exception a déjà ce qu'il faut. Mais si tu essayes de réagir en fonction du problème exact qui s'est produit, c'est plus dur :)

Mais alors dans ce cas, je mets quoi comme message pour ArgumentNullException par exemple? Dans le code ci dessous, elle peut être levée par plusieurs instructions différentes et c'est le cas d'autres exception.

Si tu ne vois pas comment gérer une exception au niveau où tu te trouves, c'est que ce n'es tpas le bon niveau pour la gérer. Dans le cas d'ArgumentNullException, il n'y a probablement que le niveau le plus bas, autour de l'appel à la méthode qui a balancé ça, que tu peux le gérer correctement.

Et si tu ne peux pas le gérer, propage. Faire un catch pour logger le message, ça ok, mais que ça se termine par 'throw' (tout court. pas 'throw ex').
(sauf dans les rares cas où le but est vraiment de masquer toutes les exceptions :)

[Maniak]

Euh ... Je vais pas mettre un try catch à chaque ligne de code quand même ... Sinon j'arrête la prog

C'est là qu'on commence à chercher des compromis :)

Je suis d'acord avec Piotrek, la série de catchs en fin de traitement, qui peuvent catcher des exceptions provenant d'une des nombreuses étapes du traitement, c'est pas glop.

Un try/catch par ligne, c'est pas glop non plus.

Tu peux déjà essayer de découper ta méthode en plusieurs, toutes petites, pour chaque étape. Elles ne feront probablement pas une ligne chaque, et ça délimitera mieux les endroits où intercepter les exceptions.

Les accès aux fichiers, c'est tout de suite très lourd niveau exceptions quand on essaye de tout gérer proprement... Mais là encore, tu n'as pas forcément à gérer tous les types d'exceptions possibles.
Les exceptions sur les arguments, tu peux tester avant les appels aux méthodes pour être sûr que ça n'arrivera pas.
IOException/SecurityException, ce sont des classes plus générales. C'est un peu comme Exception, qu'est-ce que tu peux en tirer comme conclusion mis à part pour logguer le message ?

Il faut essayer d'isoler autant que possible ces méthodes qui sont susceptibles de balancer des trouzaines d'exceptions. Quitte à faire des wrappers de ton cru qui convertissent les exceptions en traitements moins radicaux. Par exemple des évènements pour prévenir d'éventuels observateurs, et suivre ensuite un comportement 'défaut' (le principe du pattern Null Object qui colle bien pour éviter les ArgumentNullException, justement :)

[Keihilin]

La gestion des exceptions c'est souvent plus philosophique que vraiment technique...

Juste pour reprendre quelques points :

Faire qqch comme :

Code :

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

1
2
 
catch ( Exception ex) { throw new MyException(ex); }

C'est à proscrire si possible. Ca ne facilite pas le débug, c'est lourd, et souvent ça n'apporte rien de plus que l'exception d'origine (mis à part, peut être, des informations complémentaires mais j'y reviens plus tard.
Bref, c'est un bon exemple de l'adage qui veut que les 2/3 des catch soient inutiles.

Je pense qu'il faut réfléchir sur plusieurs points de vue :

1) Est-ce que je peux faire quelque chose avec cette exception ?

Prenons la FileNotFoundException dans ton code...Si lorsque cette exception est levée tu décidais de créer le fichier qui n'existe pas et de relancer un traitement de manière totalement transparente, là ton catch aurait un sens; dans le cas contraire, on laisse se propager.

2) Dans une application à composants découplés, est-ce que la responsabilité de traiter ou de décorer une exception incombe à tel ou tel composant ?

MA réponse est que ça dépend. Si l'exception concerne précisemment une tâche qui incombe au composant : oui, dans le cas contraire : non.

En clair : ArgumentNullException, ArgumentOutOfRangeException, FileNotFoundException, etc...tu laisses se propager. C'est à la couche supérieure de traiter, décorer, compléter, traduire et enregistrer l'exception.

[zeavan]

bon et bien je saute sur l'occasion pour vous demandez votre avis .

Je crois avoir un retissement mal fonde surement sur les try & catch,
en gros si je peux les eviter et bien je les evite a tout pris en verifiant si un fichier existe bien d'abors ou si un nombre n'est pas egal a 0 avant de diviser et ainsi de suite.

Ma question est-ce bien utile donc que je me prenne des fois la tete plutot que de mettre un try & catch et pour resoudre le probleme.

En gros au debut je met des try & catch puis petit a petit je les supprime lorsque j'arrive a gerer les exceptions d'une autre facon.

qu'en pensez-vous?

[StormimOn]

Ma question est-ce bien utile donc que je me prenne des fois la tete plutot que de mettre un try & catch et pour resoudre le probleme ?

J'aurai tendance à dire que ca vaut le coup dans les cas simples que tu cites, comme tester l'existance d'un fichier avant d'essayer de l'ouvrir ou le dénominateur avant de faire une division, parce que cela va éviter la levée d'une exception. Les exceptions c'est bien, mais quand on peut éviter de les lever c'est bien aussi, du moins je pense

[davcha]

L'avantage de lever une exception c'est que par la suite, dans un try catch, on peut faire un peu ce qu'on veut.

Par exemple, si on a une classe qui est munie d'un contructeur doté d'un paramètre formel, et que le paramètre formel est un string qui doit avoir un certain format (une adresse IP, par exemple), on peut, dans le constructeur, lever une exception ArgumentException, par exemple, avec un petit message qui va bien, du style "Parameter isnt an IP adress.".

Ensuite, quand l'utilisateur de la classe utilise cette classe, il met un try catch autour, et il peut récupérer l'erreur -- même s'il entre des choses totalement débiles -- et, gros avantage, il fait ce qu'il veut pour récupérer l'erreur, ce que ne peut pas faire un if.then.else qui aurait été directement dans le code de la classe.

Ensuite, le try catch, le gros avantage aussi, c'est tout de même qu'ils permettent de rattrapper les bugs imprévus. Quand un programme ne contient aucune erreur de prog, vous pourrez être sûr que les bugs viendront des utilisateurs qui entreront n'importe quoi, n'importe comment, et dans ces cas là, les try catch sont tout de même assez merveilleux.

Il est plus facile de dire "si ça ne s'est pas passé comme prévu, on annule tout" plutôt que "s'il se passe ceci, on fait ça, s'il se passe cela, on fait ci, etc...".
Dans le deuxième cas, l'ingéniosité des utilisateurs sera toujours supérieure à votre capacité à prévoir les conneries qu'ils pourraient faire avec votre programme (évidemment, c'est surtout vrai pour les programmes volumineux ; pour les petites moulinettes, c'est moins gênant).

[Maniak]

L'avantage de lever une exception c'est que par la suite, dans un try catch, on peut faire un peu ce qu'on veut.

C'est aussi l'inconvénient :)

Ensuite, le try catch, le gros avantage aussi, c'est tout de même qu'ils permettent de rattrapper les bugs imprévus. Quand un programme ne contient aucune erreur de prog, vous pourrez être sûr que les bugs viendront des utilisateurs qui entreront n'importe quoi, n'importe comment, et dans ces cas là, les try catch sont tout de même assez merveilleux.

En quoi est-ce qu'une gestion incomplète de la validation des données provenant des utilisateurs n'est pas un bug du programme ?

C'est à l'appli de traiter ce qui arrive des utilisateurs pour que le code derrière obtienne des données valides. Zapper la validation des entrées et compenser ça par des messages d'erreur en retour (ou un plantage de l'appli si on a raté le catch qu'il fallait), c'est pas une solution idéale :)

Il est plus facile de dire "si ça ne s'est pas passé comme prévu, on annule tout" plutôt que "s'il se passe ceci, on fait ça, s'il se passe cela, on fait ci, etc...".
Dans le deuxième cas, l'ingéniosité des utilisateurs sera toujours supérieure à votre capacité à prévoir les conneries qu'ils pourraient faire avec votre programme (évidemment, c'est surtout vrai pour les programmes volumineux ; pour les petites moulinettes, c'est moins gênant).

En même temps on n'est pas payé pour se simplifier la vie, mais pour simplifier celle des utilisateurs.
Leur faire réentrer des données parce qu'on a eu la flemme de faire une validation exhaustive, on a vu mieux comme approche.


Pour en revenir à zeavan, oui, tout ce que tu peux faire pour éviter de te retrouver avec une exception, ça vaut le coup. Les exceptions, c'est pour quand il y a un problème qui ne peut pas être géré à l'endroit où il se produit. Là où ça devient philosophique, c'est pour déterminer ce qui pourrait être une gestion correcte de l'erreur à l'endroit en question.

S'il faut arrêter le déroulement de l'application et faire remonter l'erreur, les exceptions peuvent servir. S'il est possible de corriger l'erreur au passage et de continuer l'exécution avec un comportement fiable, go go go. C'est sûr que ça fait plus de boulot pour le dév, mais c'est un peu son job.

[zeavan]

merci pour la confirmation maniak.