Discussion :

[serhhio]

Bonjour

Je cherche une documentation +- lucide pour expliquer les choses suivantes:

* pourquoi on doit générer des exceptions en .NET (moins on a, mieux on vit?!);
* pourquoi on doit pas associer une génération d'exception à un ...MessageBox (informer l'utilisateur des anomalies toute suite?!).

quelle littérature (de préférence en Français) vous me recommanderiez.

(pour être franc, c'est pas pour moi, moi juste je peux pas expliquer aux collègues)

[tomlev]

Ca sert à faire planter ton programme

Non, je rigole...

pourquoi on doit générer des exceptions en .NET (moins on a, mieux on vit?!);

Parce que c'est le moyen le plus pratique de gérer les erreurs. Ca permet de donner des informations précises sur l'erreur : type d'erreur, informations associées, emplacement où l'erreur se produit (stack trace)... De plus, ça permet d'intercepter l'erreur là où ça t'arrange plutôt qu'à l'endroit précis où elle se produit, puisqu'une exception se propage en remontant la pile jusqu'à l'endroit où elle est interceptée.

L'autre technique "classique" pour la gestion d'erreur est de renvoyer un "code de retour" ou "code d'erreur", qu'il faut ensuite interpréter et qui donne beaucoup moins d'informations. De plus la propagation de l'erreur se fait beaucoup moins naturellement qu'avec les exceptions.

pourquoi on doit pas associer une génération d'exception à un ...MessageBox (informer l'utilisateur des anomalies toute suite?!).

Qui a dit qu'on ne devait pas ? Ca dépend des cas... Effectivement il ne faut pas faire ça en plein milieu du code métier, parce que ça violerait la séparation du code métier et de l'interface graphique. Mais au niveau de l'UI, ça n'a rien d'anormal d'afficher une MessageBox pour signaler le problème. Par contre, si c'est une exception à laquelle tu t'attends et dont tu connais la cause, n'affiche pas le message d'erreur (l'utilisateur ne le comprendrait pas), affiche plutôt un texte adapté à la situation.

Si vraiment c'est une erreur inattendue, ça peut être utile d'afficher ses détails pour que l'utilisateur puisse les transmettre au support (en général je développe une boite de dialogue exprès pour ça, avec possibilité d'envoyer directement un mail au support ou au moins de copier les infos dans le presse-papier)

quelle littérature (de préférence en Français) vous me recommanderiez.

Jette un oeil à ce tuto. Ca concerne Java et c'est en partie spécifique à Java, mais les grands principes restent applicables à .NET

Sinon, en anglais :
http://msdn.microsoft.com/en-us/library/seyhszts.aspx
http://reddevnews.com/articles/2009/...xceptions.aspx

[DonQuiche]

D'abord, prenons un peu de perspective : tu développes des applications ou sites web mais songes à a des biblios de classe... Préfères-tu que le framework te renvoie une exception que tu peux interrompre comme tu le fais aujourd'hui ou voudrais-tu qu'au moindre problème il affiche une grosse DialogBox au contenu ésotérique dans la tronche de ton utilisateur ? Pour ma part, je préfère de loin une exception que je peux ensuite traiter comme je le veux.

Maintenant, est-il intéressant pour toi, dans ton code applicatif de lever volontairement des exceptions en cas d'erreur ? Grosso modo, je vois deux cas distincts :

• Il s'agit d'une erreur silencieuse, que ton programme sait contourner pour poursuivre l'opération en cours, quitte à demander à l'utilisateur de préciser la conduite à suivre. Tu peux soit gérer ça via une exception qui sera intercepté par une méthode précédente dans la pile des appel, soit utiliser un autre mécanisme (code de retour, paramètre byref, membre, appel direct d'une MessageBox, etc). La bonne solution sera la plus simple à mettre en œuvre selon le contexte, les considérations architecturales, l'élégance du code et, parfois, des critères de performances. A voir au cas par cas.
  
• L'autre catégorie est celle des erreurs irréversibles qui entraîneront soit la fermeture de l'application ou l'interruption du traitement/opération en cours. Il peut s'agir d'erreurs fatales, de bugs, de scénarios non-envisagés (exceptions inattendues), etc. Dans tous les cas il te faudra fournir une alerte UI. Le plus simple me semble être de gérer ça via les exceptions puisque cela te permettra, en plaçant un groupe "catch" à la racine des appels du traitement en cours, d'obtenir un mécanisme te permettant capturer n'importe quelle erreur afin de fournir une réponse commune (avec quelques variantes éventuellement, tel qu'un message spécifique selon le type de l'exception).

Maintenant, peut-être ta question était-elle : "pourquoi ne pas directement afficher une MessageBox à l'endroit où l'on aurait levé une exception ?" Dans ce cas, j'ajouterai à ce qui précède l'importance de la séparation des responsabilités du code (tes business objects ne devraient pas déclencher des actions UI : maintenabilité, etc ; il s'agit d'une des contraintes architecturales auxquelles je me référais plus haut) et en ajoutant qu'une simple MessageBox ne suffit pas : il te faut aussi sortir de traitement en cours et faire le ménage. Une exception interceptée à la racine des appels du traitement en cours couvre tout cela et laisse en plus les appels intermédiaires procéder eux aussi à un éventuel nettoyage spécifique (et ces appels intermédiaires peuvent être dans des méthodes virtuelles qui seront peut-être surchargées dans un an et qui réclameront un traitement spécifique en cas d'erreur).

[serhhio]

au niveau de l'UI, ça n'a rien d'anormal d'afficher une MessageBox pour signaler le problème. Par contre, si c'est une exception à laquelle tu t'attends et dont tu connais la cause, n'affiche pas le message d'erreur (l'utilisateur ne le comprendrait pas), affiche plutôt un texte adapté à la situation.

Le problème est un peu dans l'autre. Par exemple on a une bibliothèque des UserControls.

On a un mécanisme d'affichage des erreurs (grosso modo une TextBox modifiée).
Alors, est-il raisonnable de remplacer tous les

Code :

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

throw new MyException(MyMessage)

par

Code :

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

MonEspaceDeNoms.MonMessageBoxDErreur(MyMessage)

?

je crois pas, car la dernière variante n’empêche pas le code d'aller plus loin... donc il faut ajouter des "returns", et puis, throw jete l'exception et n'execute pas les autres fonctions jusqu'au premier catch, tandis que la variante "Display=>Return" va suivre l'instruction suivante...

PS.
Voila j'ai lu la réponse de DonQuiche, je suis entièrement d'accord avec une telle position.

[Er3van]

je crois pas, car la dernière variante n’empêche pas le code d'aller plus loin... donc il faut ajouter des "returns", et puis, throw jete l'exception et n'execute pas les autres fonctions jusqu'au premier catch, tandis que la variante "Display=>Return" va suivre l'instruction suivante...

La première non plus. En fait tout dépend de ce que tu veux dire par "aller plus loin".

Pour te donner un exemple :

Code c# :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
public void maFonction(...) {
    try {
          methodWhichThrowsException();
          try {
              anotherMethodWhichThrowsBusinessException();
          }
          catch(BusinessException be) {
              throw new Exception("Exception Métier : "+be.Message) ;
          }
    }
    catch(Exception e) {
         MessageBox.Show("Exception levée : "+e.Message);
    }
}

Et ça t'affichera : "Exception levée : Exception Métier : " + le détail de ton exception métier que tu as implémenté et fait dérivée d'Exception.
Tu auras bien le code qui va "jusqu'au bout" en exécutant les deux méthodes.

[ced600]

Un des intérêts de l'exception est liée au bloc try catch finally.
Le bloque try entoure le code pouvant généré une exception.
Le bloc catch sera executé en cas d'exception, attention ton code à l'intérieur peux lui aussi généré des ecxeptions et donc nécessité des try catch.
Le bloc finally contiendra le code qui sera toujours exécuté qu'il y ait ou non exception. Même remarque qu'au dessus, faire attention à ce que celui-ci ne puisse pas générer d'exception ou gérées celle-ci.

Un exemple simple à comprendre de son intérêt est la connexion de ton programme à une base de données, par exemple l'appel d'une procédure stockées.
Cette action peux générer des exceptions diverses et variées à différents moments de l'appel ou l'execution de la procédure stockée. Si tu ne gère pas ces exceptions, tu te retrouves tres vite avec un nombre incalculable de connexion ouverte inutilement sur la base de données et une baisse de performance.
Quelque soit le problème d'accés ou de traitement, le programme dans tous les cas (fonctionnel ou non) doit s'assurer de la fermeture de la connexion à la BD et la fermer si besoin.
Le bloc finally permet de répondre à ce besoin.

Ce n'est possible que si la remontée d'erreur se fait par exception et ce bloque finally offre une simplicité de gestion dans cette remontée d'erreur que l'on aurait pas en n'utilisant pas les exceptions.


Par contre une dérive et mauvaise utilisation des exceptions est de catcher toutes les exceptions pour ne rien faire, ni mettre dans des logs, ni remonter d'information à l'utilisateur, ni traiter l'exception. Bref juste pour masquer une exception levée, qui n'empeche le traitement de la méthode, mais qui révéle un bug sous jacent que l'on ne comprend pas et dont on ne prend pas le temps de traiter.
Cela m'est arriver de trouver dans du code une telle utilisation du bloc try catch pour ne pas gérer une telle exception, une portion de code datant de plus d'un an révélant à l'époque un bug sous jacent qui ne s'est manifesté visuellement et/ou fonctionnellement qu'un an plus tard.