Discussion :

[cobolfingaz]

Bonjour à tous,

Je travaille sur une solution qui contient plusieurs assemblies. L'une d'entre elle contient des classes contrôles qui agissent sur des couches inférieures à mon application (base de données, traitement de fichiers sur disque, etc.)

Ces classes font appel à des fonctions qui peuvent souvent lancer des exceptions (ouverture d'une connexion à la base de données, écriture dans un fichier ...)

J'appelle ces classes à partir de ma couche la plus près de l'utilisateur (les Windows Forms) et ma façon de faire actuelle pour trapper les exceptions est de le faire à ce niveau et non au niveau des classes contrôles.

J'ai lu sur msdn à ce sujet et je ne suis pas certain si je ne fais pas tout ça à l'envers ou si je ne gère tout simplement pas bien les exceptions.

Par exemple, j'ai une classe contrôle qui s'occupe d'ouvrir la connexion à une base de données et de me retourner des données précises par le biais de ses méthodes. Je ne fais pas de gestion d'erreur (exemple : mettre mon sqlConnection.Open() dans un bloc try) à ce niveau, puisque je ne peux pas (lire : je ne VEUX pas) retourner de message d'erreur à l'utilisateur à ce niveau.

J'ai remarqué dans certains exemples sur des blogs, qu'à ce niveau, on peut trapper l'exception et la relancer, mais, à mon avis, c'est inutile, à moins d'ajouter un message plus spécifique à l'exception ou lancer un nouvelle exception, puisque je vais quand même trapper l'exception au niveau de l'utilisateur.

Justement, c'est à ce niveau que je me questionne. Ma classe contrôle possède par exemple, une méthode qui ouvre la connexion à une base de données, lance une requête, pousse les résultats dans une classe entité, et la retourne à ma Windows Form pour traitement et affichage. Pour m'assurer qu'une gestion des exception est faite, je mets l'appel à ma méthode dans un bloc try.

Certains diront sûrement que c'est une bonne façon de faire, mais je me questionne quand même sur la latitude que je peux donner à ma gestion d'exceptions.

Si je veux, par exemple, trapper les exceptions de type ArgumentException, ainsi que OperationException, je me ramasse avec un code comme celui-ci :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
try
{
    classeDB.RetourneElements(parametre);
}
catch (ArgumentException ex)
{
    MessageBox.Show("Un argument est invalide");
}
catch (OperationException ex)
{
    MessageBox.Show("Opération invalide");
}

Premièrement, l'utilisateur n'a pas besoin d'avoir un message aussi détaillé dépendamment de quelle exception a été lancée. C'est pour ça que je me questionne sur la gestion d'exception faite uniquement au niveau le plus "haut" de l'application. Bien sûr faudrait-t-il faire une gestion d'exception au niveau de mes classes contrôles, mais je ne sais pas comment bien balancer tout ça, et éviter une redondance (trapper la même exception sur deux niveaux).

Malheureusement, la documentation sur msdn à ce sujet est très brève et ne me permet pas d'avoir un "bon design" au niveau de la gestion d'exceptions.

Quelqu'un pourrait-il me suggérer une bonne façon de faire ?

Merci d'avance,

[hed62]

Selon moi, chaque couche doit gérer les exception, et en relancer une compréhensible par la couche supérieure.

Je m'explique : Les couches très basses vont se récolter des exceptions très basses (type I/O, etc...), elles doivent les encapsuler et renvoyer à la place des exceptions d'un niveau moyen ("Erreur fatale" , "Login/MDP incorrect"). La couche UI, elle, recoit ces exceptions et
- soit les encapsule avant de les montrer à l'utilisateur
- soit les envoie telles quelles.

[cobolfingaz]

J'en prends bonne note. Merci ! :-)