Discussion :

[_skip]

Bonjour,

Au cours de mes recherches sur le net (forums, exemples, tutoriaux, etc..) il m'a semblé constater que la gestion d'exception était un mécanisme souvent mal compris ou mal appliqué.

On voit souvent des catch(Exception e) tout au sommet, des blocs catch vides qui dissimulent l'erreur etc...

Je me suis donc demandé si un article regroupant quelques explications, la mise en évidence des erreurs fréquemment commises ainsi que quelques *best practices* trouverait sa place dans la rubrique .Net ?

[efficks]

Bien c'est pas bien compliqué.
- Utiliser l'exception le plus haut niveau possible. Par exemple DivisionByZeroException au lieu de Exception.
- Diviser les exception dans plusieurs catch pour un même bloque pour les traiter individuellement.
- Prévenir les erreurs car le traitement d'exception est très coûteux. Par exemple, vérifier le diviseur avant de diviser au lieu de traiter l'exception. Prends moins de temps.

[_skip]

Ca ce sont les "best practices", il y a aussi le fait que l'on ne doit catcher que les exceptions que l'on a anticipé et pour lesquels on a effectivement prévu de réagir (inutile par exemple de gérer OutOfMemoryException), utilité du try-finally (pour nettoyer ou libérer les ressources derrière soi sans forcément intercepter), différence entre throw; et throw ex; dans un bloc catch. La clause using etc...

Il me semble que ce sont des choses qui échappent à beaucoup de monde même si elles sont pas bien compliquées.

[Ditch]

Je me suis donc demandé si un article regroupant quelques explications, la mise en évidence des erreurs fréquemment commises ainsi que quelques *best practices* trouverait sa place dans la rubrique .Net ?

Tout à fait, je pense également que ce serait très intéressant de proposer des best practises

[Skalp]

Qui peut rédiger cet article ? _skip ?
J'ai hâte de le lire ^^

[_skip]

Je pourrai sans doute essayer, faudrait juste que quelqu'un d'autre check derrière moi histoire que certains points de vue ne soient pas trop personnels

[Keihilin]

ça fait un moment que j'y pense mais je n'ai jamais concrétisé par manque de temps...

A deux ça serait peut être plus facile, donc je veux bien co-signer un tel article si on trouve un plan permettant de partager la rédaction.

[_skip]

Je pense que ce serait possible.
Dans les grandes lignes, mon idée à travers cet article serait de ne pas se focaliser sur la définition des exceptions elles-mêmes ( tous les tutoriels du net font cela très bien), mais plutôt de mettre en évidence les erreurs fréquemment commises et de proposer quelques best practices.

Ce pourrait être sans ordre spécifique :

1) la mise en place d'une gestion intelligente, pas de catch(Exception), pas de swallowing, différence entre "throw;" tout court et "throw ex;".
2) Expliquer qu'il est parfois préférable de "laisser exploser" que de catcher lorsque la situation n'est pas controllable, ou lorsqu'on a tout simplement pas prévu le coup.
3) le nettoyage derrière soi, clause finally, using avec objets IDisposable... etc..
4) le débat "prevention de l'exception" vs "reaction a l'exception" qui ont tous les deux une raisons d'être suivant les situations. Ainsi que le dilemme entre prévoir une gestion d'exception pour un traitement ou faire confiance?
5) Utilisation d'exceptions personnalisées pour encapsuler des exceptions du framework et prévoir des messages d'erreur amicaux.
6) Logger les exceptions non gérées (erreurs fatales) au moyen d'un handler global pour une application qui tourne en production.

L'idée ne serait pas de dicter une conduite rigide mais d'introduire un point de vue utilisable pour des applications real-world.
Qu'en dites-vous?

[Keihilin]

1) la mise en place d'une gestion intelligente, pas de catch(Exception), pas de swallowing, différence entre "throw;" tout court et "throw ex;".

Partie facile, recommendations simples à suivre et facilement justifiables.

2) Expliquer qu'il est parfois préférable de "laisser exploser" que de catcher lorsque la situation n'est pas controllable, ou lorsqu'on a tout simplement pas prévu le coup.


J'étendrai ceci à un principe plus général : La propagation. Etudier d'un point de vu architectural le comportement à appliquer face à une exception en fonction du composant, de son rôle et de son emplacement dans les couches.


3) le nettoyage derrière soi, clause finally, using avec objets IDisposable... etc..

Même chose que 1), partie assez simple.

4) le débat "prevention de l'exception" vs "reaction a l'exception" qui ont tous les deux une raisons d'être suivant les situations. Ainsi que le dilemme entre prévoir une gestion d'exception pour un traitement ou faire confiance?

Partie très intéressante mais la plus compliquée je pense. Je mettrai ça comme extension de la partie 2). Ca va nécessiter des cas concrets, des benchs...

5) Utilisation d'exceptions personnalisées pour encapsuler des exceptions du framework et prévoir des messages d'erreur amicaux.
6) Logger les exceptions non gérées (erreurs fatales) au moyen d'un handler global pour une application qui tourne en production.


L'instrumentation...ça peut vite tourner au débat philosophique

[_skip]

2) Expliquer qu'il est parfois préférable de "laisser exploser" que de catcher lorsque la situation n'est pas controllable, ou lorsqu'on a tout simplement pas prévu le coup.


J'étendrai ceci à un principe plus général : La propagation. Etudier d'un point de vu architectural le comportement à appliquer face à une exception en fonction du composant, de son rôle et de son emplacement dans les couches.

Comme par exemple que l'affichage d'un message d'erreur doit se gérer sur la couche UI et non pas au beau milieu d'une business layer (c'est marrant mais j'ai vu une fois un MessageBox.Show() au beau milieu d'une couche d'accès au données qui était censée etre partagée entre plusieurs projets. )

4) le débat "prevention de l'exception" vs "reaction a l'exception" qui ont tous les deux une raisons d'être suivant les situations. Ainsi que le dilemme entre prévoir une gestion d'exception pour un traitement ou faire confiance?

Partie très intéressante mais la plus compliquée je pense. Je mettrai ça comme extension de la partie 2). Ca va nécessiter des cas concrets, des benchs...

En effet peut être de façon plus générale, les scénarios typiques sont par exemples le cas du delete d'un enregistrement dans une base de donnée, doit-on systématiquement vérifier les 30 tables pouvant contenir une liaison a cet enregistrement ou simplement réagir sur une exception de violation de contrainte de clef étrangère. En tenant compte des problèmes de maintenance que cela pose si le schéma de la dite BDD évolue souvent, sans parler des performance.

Il s'agit aussi de savoir si l'environnement de l'exception est "trusted" ou non, supposons que l'on parse des strings en XML, doit-on prendre les mêmes précautions si ces strings sont produites par notre propre application ou par un logiciel développé par des tiers au moyen d'une interface? Par ailleurs y'a-t-il une chance que ces chaines XML soient altérées par un utilisateur humain?

5) Utilisation d'exceptions personnalisées pour encapsuler des exceptions du framework et prévoir des messages d'erreur amicaux.
6) Logger les exceptions non gérées (erreurs fatales) au moyen d'un handler global pour une application qui tourne en production.


L'instrumentation...ça peut vite tourner au débat philosophique

Je sais, typiquement il y a mille manières de logger des exceptions, mais j'aimerai juste rendre attentif sur le fait qu'il est important d'avoir une trace de ce qui s'est produit en production. En général on reçoit un téléphone de son client qui dit "ca plante". Il est rare qu'on puisse compter sur lui pour nous donner plus détails. Connaitre la nature technique d'une erreur fatale est déjà un début.
Peut être en effet que sur l'encapsulation ça risque d'être trop subjectif, on pourrait cependant montrer que les messages d'erreurs super verbeux et amicaux émis depuis le fin fond d'une couche métier peuvent rendre la maintenance pénible dans le cas ou l'application possède une couche GUI destinée à etre traduite. Autant avoir dans cette couche GUI une méthode qui construit un message sympa dans la bonne langue a partir d'une exception.

[Skalp]

Tous ces thèmes me semblent très intéressants

Je me permets de faire une synthèse de vos idées pour faire avancer le débat sur le fond de l'article et y ajouter quelques propositions (en vert) :

Principe général : mettre en évidence les "worst" practices et donner des best practices.

Introduction
- généralités sur les exceptions (try/catch/finally)
- définir une exception => liens vers des tutoriels

Gestion des exceptions
- différence entre throw et throw ex
- nettoyage post exception : clause finally, objets IDisposable, using
- environnement "trusted" ?

Les exceptions et les couches applicatives
- principe : nature et localisation des exceptions en fonction de la couche
- couche business
- couche data access
- couche GUI
- couche de stockage des données ?

Propagation et architecture
- laisser filer l'exception ou catcher ?
- prévenir ou gérer une exception ? (Cas concrets, bench)
- architecture de propagation au sein d'une application
- Couche "exceptions", transversale aux couches business, data access et UI ? (http://morpheus.developpez.com/architecture/)

"Instrumentation" des exceptions
- messages d'erreurs amicaux
- Exceptions personnalisées
- Log des exceptions (principe : avoir une trace des erreurs)


A vous de critiquer ce plan et d'y apporter vos modifications


Voici des liens vers des articles dvpz.com qui pourront vous aider dans la rédaction de l'article :
- [C++] Chapitre 9. Les exceptions en C++
- [Java] Les exceptions et les bonnes pratiques
- [Delphi] Chapitre 103 : Gestion des exceptions

[Keihilin]

- Couche "exceptions", transversale aux couches business, data access et UI ? (http://morpheus.developpez.com/architecture/)

Je suis partagé sur ce point...Si je l'aborde, je vais être dans l'obligation de récuser un article écrit par un confrère...enfin bon, pas l'article dans son ensemble, mais ce point précis que je ne range pas dans les "best practices"...

[Skalp]

Ah oui ? Tu ne penses pas qu'une couche exception, transversale aux autres couches soit pertinente ?

Comment verrais-tu l'architecture ?

[Keihilin]

Comment verrais-tu l'architecture ?

Non, je ne pense effectivement pas que ce soit pertinent...
Par extension, je suis assez dubitatif concernant la couche transversale d'objets métiers, mais je ne peux pas en expliquer les raisons en quelques lignes; cela demanderai un article complet...J'y pense depuis un moment.

Par ailleurs, je n'ai pas dit que je considérais cela comme un anti-pattern.

[_skip]

Voici des liens vers des articles dvpz.com qui pourront vous aider dans la rédaction de l'article :
- [C++] Chapitre 9. Les exceptions en C++
- [Java] Les exceptions et les bonnes pratiques
- [Delphi] Chapitre 103 : Gestion des exceptions

Mes excuses si je ne l'ai pas précisé, je souhaitais surtout aborder les exceptions de la plateforme .Net.
Je pense en effet partir du principe que le lecteur sait ce qu'est un bloc try...catch, quitte a proposer un lien vers un autre article d'introduction à dot net.

Je souhaiterai juste émettre une petite réserve par rapport au plan proposé :
Expliquer le phénomène de propagation à travers les couches est une bonne chose mais il est important d'éviter de *dévier* vers un cours d'architecture logicielle.

Les informations sur les sujets autres que les généralités seront plus des conseils argumentés qu'autre chose, l'un des fins mots de l'histoire sera surtout la "maintenance" dont je me servirai pour défendre la plupart desdits conseils.
Typiquement lorsqu'on abordera des sujets tels que l'encapsulation d'une exception du framework au sein d'une exception personnalisée, je souhaite faire comprendre l'intérêt de cette pratique en fournissant un exemple.

Expliquer pourquoi il n'est pas forcément malin, lorsque le GUI essaie de procéder à une identification de l'utilisateur par le biais d'une méthode BL qui passe finalement par la lecture d'un fichier XML suivi d'un accès sur une base de donnée, de le laisser se prendre un IOException ou un SQLException brut dans la figure. En effet, ces erreurs pourraient être encapsulées dans un "LogonFailureException" personnalisé au sein de la BL, ce qui permettrait a l'appelant de ne gérer qu'une seule Exception au lieu de 12 différentes tout en ayant accès aux causes profondes du problème via InnerException.
Par ailleurs dans ce même exemple, souligner que si la procédure de logon change quelque peu dans son code suite à une révision et ne génère non plus 12 exceptions mais seulement 10, dont 2 ne sont plus les mêmes qu'auparavant c'est agréable si cela n'affecte pas trop les multiples endroits dans l'application ou la méthode d'autentification est appelée.

Ce sont des suggestions, le tout est se s'efforcer de faire ressentir leur pertinence sans affirmer "c'est comme ça et pas autrement". Quoi qu'on en dise, cela gardera toujours une part de subjectivité.

[npuzin]

C'est vrai que la gestion des exceptions n'est pas forcément triviale, voici mon expérience à ce sujet.

Catcher ou non une exception / rapport de bugs ?

Une problèmatique récurrente est de savoir s'il faut catcher ou non une exception.

Lorsque l'on gère les exceptions avec un envois de rapports de bugs automatique dans une base de bugs, il est important de ne pas se tromper.

L'idée est que :
- si l'exception n'est pas catchée, un rapport est envoyé aux devs
- si l'exception est catchée, les devs ne recoivent rien

Donc si on ne catch pas une exception qui survient 300 fois par jours chez vos utilisateurs et que ce n'est pas un bug à corriger, votre base de bugs va rapidement etre floodée. Par exemple, si votre application utilise un serveur de base de données, le jour où le serveur est en maintenance (c'est inévitable ça arrive !), vous recevrez 300 fois le message comme quoi la connexion a échoué alors que les devs n'y sont pour rien. Dans ce cas la donc il faut catcher l'exception.

A l'inverse, si on catch un vrai bug qui doit être corrigé rapidement, les devs ne recevront pas de rapport et donc ils ne seront pas au courant tant que le 1er utilisateur a bout de nerf appelle la hot line.

Bloc catch vide

J'ai déjà vu des developpeurs faire un truc qui pour moi est une mauvaise pratique, je ne sais pas ce que vous en pensez :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
public void MonTraitement()
{
   try 
   {
      // code du traitement
   }
   catch 
   {
      // on ne fait rien
   }
}

La bonne pratique étant qu'il faut éviter impérativement les blocs de catch vides car celà signifie qu'on a potentiellement du code qui n'est pas exécuté et qu'on a aucun moyen de le savoir. Eventuellement si le try ne contient qu'une seule ligne, et que ce n'est pas grave si cette ligne plante, on peut faire ca (mais c'est un cas qui me parait extremement rare).

[_skip]

Ce que j'utilise pour ma part et qui marche plutot bien en production, c'est simplement d'attacher un handler d'exception globale a mon thread main de façon à ce que je puisse logger toute exception fatale.
Je suis pas convaincu qu'envoyer automatiquement des rapports d'erreurs soient toujours une solution puisqu'une exception non catchée est pas forcément un bug.

Ton deuxième exemple c'est du swallowing, c'est véritablement une erreur dans 99.99 pourcent des cas et on en trouve effectivement beaucoup dans les petits bouts de code qui trainent sur le net.

[npuzin]

Ce que j'utilise pour ma part et qui marche plutot bien en production, c'est simplement d'attacher un handler d'exception globale a mon thread main de façon à ce que je puisse logger toute exception fatale.

Tout a fait

Je suis pas convaincu qu'envoyer automatiquement des rapports d'erreurs soient toujours une solution puisqu'une exception non catchée est pas forcément un bug.

Peu importe, si les utilisateurs ont un bouton "envoyer un rapport de bug", ils cliqueront et tu recevras un rapport qui sera pour la poubelle.

Par contre c'est justement la démonstration que j'ai voulu faire dans mon post précédent, on est pas d'accord alors, pour moi la best practice est :

- si c'est un vrai bug à corriger, l'exception ne doit impérativement pas être catchée
- si c'est une erreur qui peut se produire mais que ce n'est pas un bug du programme, cela doit être catché, ou alors il faut faire en sorte que l'exception ne se produise plus

Trouve moi un cas où il est justifié de laisser passer une exception en sachant :
- que généralement tu vas afficher une vieille fenêtre d'erreur à l'utilisateur avec la Stack Trace et tout (ça risque de lui faire peur)
- ca va faire ramer sa machine car l'envois d'une exception c'est consommateur de ressource

[_skip]

- que généralement tu vas afficher une vieille fenêtre d'erreur à l'utilisateur avec la Stack Trace et tout (ça risque de lui faire peur)

Dans le handler global, j'ai justement une fenetre qui informe que l'application va se terminer suite à une erreur rencontrée, l'utilisateur n'a pas accès a plus d'information directement.

- ca va faire ramer sa machine car l'envois d'une exception c'est consommateur de ressource

Une seule exception levée, ce n'est pas suffisant pour faire ramer une machine, si tu mitrailles avec des throw dans une boucle c'est un autre problème mais lever une seule exception qui termine le programme, c'est très péniblement remarquable pour l'utilisateur.

Trouve moi un cas où il est justifié de laisser passer une exception

Lors de l'écriture ou de la lecture d'un fichier de configuration, si les droits d'écriture dans le répertoire ne sont pas suffisants ou si le disque est plein je laisse propager, je m'assure juste d'avoir bien nettoyé derrière mon code. En revanche, je catche si le document est mal formé dans le cas de XML éditable par l'utilisateur.
Ce sont des exemples, mais en général je ne catche pas lorsque que je n'ai pas anticipé l'exception ou lorsque je n'ai pas de scénario qui permet de récupérer de l'erreur en toute sécurité. En fait j'ai bien plus de try..finally et de using() dans mon code que je n'ai de catch.
Typiquement, en cas d'erreur lors d'une requete sur la base de donnée, s'il ne s'agit pas d'une erreur que j'ai anticipée je la laisse remonter, je m'assure dans mon finally d'avoir proprement fermé la connexion et rollbacker une éventuelle transaction mais c'est tout, ensuite si ca plante l'application, peut etre que je me ferai engueuler par le client mais au moins je saurai qu'il se produit des choses dans mon application que je n'ai pas prévues.

A mon sens, vouloir a tout pris catcher et gérer toutes les exceptions possibles pour un traitement c'est une fausse robustesse, je le ressens presque comme une incompréhension du concept.

[npuzin]

En fait j'ai bien plus de try..finally et de using() dans mon code que je n'ai de catch.

Tout a fait d'accord

A mon sens, vouloir a tout pris catcher et gérer toutes les exceptions possibles pour un traitement c'est une fausse robustesse, je le ressens presque comme une incompréhension du concept.

Je n'ai absolument pas dis qu'il fallait essayer de tout catcher y compris un OutOfMemory et des choses comme ca qui n'arrivent jamais. Mais si on reprend ton exemple du fichier sur lequel l'utilisateur n'a pas les droits, si ca arrive une fois par an, tu ne catch pas, mais si ca arrive 25 fois par jour, il y a un moment ou il va falloir que tu geres proprement ton truc. Si ca arrive fréquemment c'est quand meme mieux d'afficher une fenetre d'erreur normale plutot que la fenetre en cas d'exception avec le bouton "envoyer rapport de bug" ou de polluer tes logs avec une erreur qui n'en est pas vraiment une.

Je reformule :

Il n'y a pas de raison d'empêcher une exception d'être propagée sauf si c'est une exception qui se produit fréquemment et que ce n'est pas un bug du programme. Dans ce cas, celle-ci peut être catchée à moins de faire le nécessaire en amont afin qu'elle ne se reproduise plus.

Vous êtes d'accord avec ça ?