Gestion des exceptions : logique qui m'étonne

**zax-tfh** · 02/04/2007, 16h29

Bonjour à tous,

Je suis confronté à quelque chose de nouveau pour moi (jeune padawan en developpement) au niveau conception de la gestion des exceptions.
Je me pose une question existencielle concernant la séparation de la partie interface et la partie métier mais également concernant le nombre de classes que l'on doit créer pour gérer des exceptions. Je m'explique :

Imaginons une classe Lambda qui est chargée de réaliser des actions.
A l'interieur il peut y avoir des actions qui ne sont pas réalisables comme ajouter un élément déjà existant ou autre. Pour cela, si je vois que l'element existe déjà, je lève une exception pour remonter l'info au niveau interface utilisateur.

Mon problème se situe au niveau de ces classes. Quand je regarde sur le net, je vois que tout le monde fait à peu près la meme chose :

Je créé ma classe ErreurExisteDéjà et dans sa propriété message je renvoie la phrase "Erreur, l'element existe déjà".
exemple VB.net :

Code :

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

1
2
3
4
5
6
7
8
9
Private Class MonException
            Inherits Exception
 
            Public Overrides ReadOnly Property Message() As String
                Get
                    Return "Le textbox ne doit pas etre vide"
                End Get
            End Property
        End Class

Or en faisant cela je vois deux illogismes que j'aimerai comprendre :
1) On créé autant de classes d'erreur que de message à remonter, pour une grosse appli ca fait énormous !!!!
2) On renvoie un texte contenu dans une classe d'erreur... Ou est la séparation entre le coté IHM et le coté métier ?

Perso, je me dis que je prefere renvoyer un code erreur et ensuite faire une correspondance au niveau de l'IHM mais bon, j'aimerai comprendre quand meme...
Donc j'aimerai savoir pourquoi c'est géré comme cela ou alors comment vous vous réalisez votre gestion d'exceptions svp.

Merci d'avance

@ bientot

**Lunelame** · 02/04/2007, 18h14

Alors, je ne saurais répondre au jeune padawan en developpement, mais si c'est juste pour le texte, utilise
Try
Throw New Exception("...Ton Texte...")
Cacth ex as Exception
... avec par exemple Console.Write ex.message
End Try

C'est tous aussi bien.

L'utilisation d'une exception que tu créer est pour gérer de façon très fine ton code. Tout dépend de ce que tu souhaite faire.

@ +, et ne bascule pas du côté obscure ... :-)

**zax-tfh** · 02/04/2007, 20h24

Salut LuneLame

En fait, j'aurais pas du mettre la mention padawan, car je suis quand meme un peu experimenté, c'est juste que je debute dans le monde professionel du dev... Bref, passons.
Pour les exceptions, je parlais bien de pouvoir séparer le coté IHM du coté Métier donc séparer le texte de la classe d'exception.
Je souhaite effectivement gérer de façon très fine mes classes d'objets.
J'attaque un gros projet je ne voudrais donc pas me barrer dans une mauvaise direction.

Je répete mes question afin d'etre sur d'avoir bien expliqué mon problème :

1) pourquoi doit-on créer une classe par Exception ?
2) pourquoi renvoie-t-on un message texte dans une classe censée etre métier et non IHM ?

Merci d'avance

**Lunelame** · 04/04/2007, 11h42

Alors, je pense que tu réfléchi dans le mauvais sens.

Tu pense à une erreur, une classe exception, un message donnée.
Or le procéder est fait pour créer des classes générique réutilisable.
Par exemple, la classe InvalidOperationException est utilisé à de nombreux reprises. Et il en a d'autre.
Chaque classe exception (à part la native) doit avoir un message d'erreur par défaut, et une possibilité de mettre un texte alternatif. Ce qui rend ce système extrement souple, car il n'imposse pas le message d'erreur, ni la langue utilisé.

En ce qui te concerne, tu peux pour rendre plus souple ton code, créer une unique classe qui t'es propre. Et y associer un fichier de ressource, dans le qu'elle tu y mets tes messages. Je vais essayer de t'en dire plus ce soir en te donnant un exemple complet (regarde la librerie Assembly).
Cette solution, bien que plus compliquer, présente de nombeux avantages. Comme la gestion de plusieurs langues, par exemple.

J'espère avoir été claire ? Vu le peut de temps que j'ai pour t'expliquer comment cela fonctionne.

@ +

**zax-tfh** · 04/04/2007, 14h06

Salut,

Merci pour tes précisions. En fait je suis en train de me demander si je ne fais pas erreur sur la reflexion globale de mon truc et si, surtout, je ne fais pas mauvais usage des exceptions. Je vais te donner un exemple concret :

J'ai une classe lambda utilisée dans un code Alpha(partie interface utilisateur) qui a une methode "CréerTruc(numero as integer)"
Dans cette méthode, je créé donc mon "Truc" mais avant je fais une vérif dans ma collection de "trucs" pour voir s'il n'existe pas déjà (via le numéro donné en parametre)

mon fonctionnement serait de faire (en algo)
Si numéro existe dans collection Trucs alors
Leves une exception du type "numeroExisteDéjà"

Comme ça, dans le code qui utilise ma classe et qui appelle CréerTruc j'ai juste à faire un catch ou je peux voir que j'ai levé une exception de type "numéroExisteDéjà" et donc je n'ai plus qu'à afficher mon message.

Les avantages que j'en tire sont les suivants :
- On sépare bien le coté métier (Lambda) du coté interface utilisateur (Alpha).
- Lorsque j'ai une erreur d'utilisation (comme le cas ou on veut créer quelque chose qui existe déjà), je n'ai pas besoin de faire des if en cascade pour gérer tous ces cas, une simple levée d'exception et eventuellement un finally suffiront.
- Le message qui sera affiché à l'utilisateur sera lancé à partir du code interface utilisateur (Alpha)

L'inconvénient que j'en tire :
- Il me faut une classe par cas d'utilisation !!!! ca fait enormement de classes ! ou alors, il faudrait que je fasse une seule classe dans laquelle je pourrais y insérer un paramètre que je pourrais récupérer du coté interface utilisateur pour savoir dans quel cas d'utilisation je me trouve.

Afin de contourner le problème et en reprenant ce que je viens de dire dans le dernier tiret, je pourrais créer une classe d'exception générique ExceptionLambda pour toute ma classe Lambda qui prendrait un parametre et lorsque je leve mon exception, je l'envoie avec ce parametre.
Quand je récupère cette exception dans ma partie interface utilisateur (Alpha) je teste déjà le type de classe d'exception (comme on le fait déjà par défaut) et donc dans le cas ou je suis dans le "catch Ex as ExceptionLambda", je n'ai plus qu'à faire un case of de ce parametre récupéré pour afficher en fonction de celui ci le message correspondant...
Que dis tu de ce mode de fonctionnement ?

Pour moi, le fait de renvoyer un message texte par défaut dans ma classe m'importe peu. Je le ferais car il me semble que c'est utilisé par le debugger et autres choses, mais je ne m'en servirais pas du tout pour moi.

Bref, je vois donc deux solutions :

1) Faire une classe par cas d'utilisation censé lever une exception donc j'aurais beaucoup de classes
2)Faire une classe d'exception pour tout mon objet et gérer via un attribut interne à cette classe les messages coté interface utilisateur.

Ces deux méthodes sont à mon avis les seules qui respectent ce que je cherche à faire, à savoir séparer le coté métier du coté IHM.
Pour ce qui est d'utiliser un fichier de ressources, comme tu l'expliques reste toujours dans la meme optique ou l'on ne sépare pas vraiment le coté métier du coté IHM.
Voilou !

Merci en tout cas

j'attend de voir ce que tu penses de tout ca
@+

**benji_dv** · 04/04/2007, 14h59

Bonjour,
Alors je vais t'exposer la manière dont je bosse,
Je définit une classe d'exception par TYPE d'exception à renvoyer ex :
- ExcAccesDB
- ExcIdentifiant
- ExcApplication
- ...
et lorsque je lève une exception, je lui passe le message dans le constructeur,
donc je ne dispose non pas d'une exception par exception à lever mais d'une personnalisation des TYPES d'exception,

Ensuite , cela te permet de filtrer les exceptions dans tes try catch et d'adopter le comportement ad hoc par type d'exception,

Il ne faut pas confondre Type d'exception et motif de l'exception

Ex : je construit une maison
mes types exception : ExcMaconnerie, ExcPlomberie, ExcElectricite

L'électricien se fait péter les cheveux au 220v => New ExcElectricite("Electricien HS");

au niveau de l'IHM
try
catch ExcElectricite
debrancher le jus
appel samu
affiche message
catch ExcPlomberie

end try

tu peux éventuellement utiliser des constantes applicatives pour les messages d'erreur...

voilou,
BenJ

**zax-tfh** · 04/04/2007, 17h16

Salut Benji_dv

En effet, ça revient un peu a la deuxieme solution que je propose sauf que toi tu utilises vraiment de la façon dont c'est expliqué partout : tu créés des classes génériques réutilisables n'importe où

Par contre pour reprendre ton exemple de construction de maison, là ou je pehce c'est ça :
imagines que tu aies deux cas avec electricien :
- electricien qui a pris du 220V
- electricien malade
Comment le gererai tu ?

Merci pour tes explications, ça affine de plus en plus mon choix (pas encore fait cela dit ^^)

++

**benji_dv** · 05/04/2007, 10h55

Bonjour,

Là,
J'opterais pour la soluce suivante

où <- montre un héritage

Exception <- ElecException <- ElecExceptionPersonne
utilié pour tous les problèmes inéhent à l'électricien,

Exception <- ElecException <- ElecExceptionSituation
utilisé pour tous le reste

Exception <- ElecException <- ElecExceptionPersonne <-ElecExceptionPersonneAccident

Ce qui me permet de faitre ceci :

try
...
catch ElecExceptionPersonneAccident 'Traitement des accidents éventuels,

catch ElecExceptionPersonne 'Traitement de toutes les autres exceptions liées à la personne

catch ElecException ' Traite toutes les autres Exceptions (quelles quelles soit) pour l'électricité

Ce qui me permet de distinguer les appels d'urgence des autres appels...

Pour rappel,
lorsque tu utilises les try catch, il y a une relation de hiérarchie de catch des exceptions !
donc si tu fais :

catch myExc as Exception
catch ElecException

le dernier catch ne se fera jamais, vu que le catch myExc as Exception se fera dans tous les cas
...

Pour mon électricien malade (même en cours de journée, il quitte le chantier)
new ElecExceptionPersonne("Je suis malade");

Ca augmente le nombre de classes, mais cela simplifie la gestion des erreurs dans l'appli...

voilou,

**zax-tfh** · 05/04/2007, 21h47

ok pour ton principe, je suis d'accord avec toi.
Maintenant, quand tu créés ton exception avec le message à l'interieur, je persiste à dire que le texte n'a pas grand chose à faire dans une classe... enfin c'est mon avis (étriqué) sur la séparation metier/présentation.
Juste une petite apparté pour expliquer pourquoi je suis si chiant avec ca, c'est qu'auparavant mon texte était un peu partout, mais question gestion c'etait une vraie misere !
Donc en fait, j'essaye aussi actuellement de voir comment ceux qui ont mis en place cette méthode universelle ont fait pour ne pas retomber à l'époque pré P.O.O. à galérer pour retrouver leurs petits.
La relation de hierarchie des catch, ok, ca je vois et c'est logique d'ailleurs.
Maintenant, si je fais la méthode 1 citée plus haut à créer autant de classes d'exception que de messages je peux toutes les faire heriter de la classe Exception et faire mes catch sur celles ci et seulement à la fin faire un catch sur la classe Exception.

Pour revenir sur la méthode que j'appelle universelle (celle que tu me cites) j'ai un exemple en tete qui montre vraiment à quel point c'est pas correct de créer une instance de classe d'exception avec un passage de message en parametre.
J'ai déjà eu à utiliser des objets distribués sur le net, notamment un qui gérait des connections FTP.
Bah le problème c'est que dès qu'il y avait un probleme de connection ou de transfert il me levait une exception que je catchais bien mais le soucis c'est qu'ils utilisaient cette méthode et donc je l'avais dans l'os car tout était en anglais... sympa pour un soft Français... Et je n'avais aucun moyen de faire le tri vu que tous ces messages arrivaient d'une classe générique du style ConnectionException et il n'y avait que le message qui changait...
A moins de faire un test sur la chaine en elle meme, y'avais pas vraiment moyen de faire ce qu'il fallait pour avoir des messages en frenchy...

Donc voila, je cherche à éviter cela quoi. Et vous ? comment vous gérez ce genre de chose ? vous codez tous en ignorant la réutilisation du code ou bien vous gérez ca proprement avec une certaine methode ?

@+ et merci

**benji_dv** · 06/04/2007, 09h27

Salut,
Je pense que pour "préciser" le type d'exception, tu peux passer en paramètre (le message de l'exception) une chaine (en francais, anglais, chinois, marsien lol, chiffrée...) , qui moyennant utilisation d'un médium (singleton, ...) te renvoie le message d'erreur associé (qui lui provient éventuellement d'un fichier ressource langue). C'est de cela lorsque je parlais d'utiliser des constantes pour les messages...

Ce qui fait que l'Exception ElecExceptionSituation
pourrait contenir les codes suivants
01 - Le fournisseur d'électricité national ne fournit pas de tension,
02 - L'électricien a trop bidouillé la prise pour qu'elle fonctionne.
...
après tu utilises le singleton (ou autre moyen fixe permettant à l'appli de récupérer le message d'erreur pour log ou affichage) où c'est nécessaire de renvoyer qqch humainement décriptable...

voilou,