En général je le fais pour savoir où est arrivé l'exception.Envoyé par Keihilin
Je m'explique.
Les exceptions, je les utilise surtout pour:
- informer l'utilisateur, si il y en a un :p (Dans les services il y en a pas)
- Si il y a un utilisateur et donc une interface, remettre l'interface dans un état "correct" pour l'utilisateur si besoin (Remettre des boutons à enable=true, etc...)
- Tracer l'exception dans un fichier (dans le code appellant)
Je suis en train de faire une librairie de composants/ Classes.
Voici un squelette d'exemple de méthodes qui utiliseront cette librairie:
J'ai toujours pensé que les try catch étant couteux, si je dois en mettre, je ne met des catchs que à la fin du traitement (sauf cas rare). Ce qui m'evite d'en mettre plusieurs dans la même méthode.
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 class CMaClass { void FaisMoiUnTruc(Object obj) { try { // Première partie du truc // Deuxième partie du truc // Compression (Je peux éventuellement tester validité des arguments avant mais ce code n'étant pas forcement du code utilisateur, je laisse les exceptions sur les arguments se propager. CFileCompressor.CompressFile(@"c:\fichier.txt", @"c:\fichier.gz", ECompressionFormat.Gzip); // Traitement XXX } catch (CFileCompressorException) { // Une erreur s'est produite lors de la compression fichier. // Je le sais car c'est CFileCompressorException } catch (CUneautreDeMesExceptionPersoXXX) { // Une erreur s'est produite lors du traitement XXX } // Suite des autres catch finally { } } };
Avec ma méthode FaisMoiUnTruc, si je laisse propager ArgumentException depuis ma classe CFileCompressor, je ne saurais pas dans quelle composant cela est arrivé à moins de faire un execption.ToString() en mode débug (pas envisageable en prod)
C'est pour cela que je décore au maximum les exceptions qui peuvent arriver dans mes composants.
Je les décore aussi pour masquer les erreurs de base de données.
Voilà
Partager