Discussion :

[Immobilis]

Salut,

J'ai créé une classe de gestion d'erreur qui hérite ainsi:

Code :

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

1
2
3
[Serializable]
public class BusinessException : System.Exception, ISerializable
{

En gros, j'ai suivit les recommandations de FXCop pour créer les méthodes de base, puis j'en ai ajouter pour réaliser des traitements particuliers (envoi d'un mail surtout).

Ainsi, dans les "try catch" de mon code, je ne fais plus de throw mais une simple instanciation de ma classe de gestion d'erreur. Celle-ci, en fonction d'une enum passée en paramètre, va stoper l'execution du script ou non par l'intermediaire d'un throw. Ce qui donne:

Code :

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

1
2
3
4
5
6
7
8
try
{
   (code...)
}
catch (DivideByZeroException ex)
{
    new BusinessException("this is a test", ex, BusinessExceptionLevel.Low);
}

Malheureusement, j'ai une alerte "DoNotIgnoreMethodResults" sur la creation de l'instance de la classe de gestion d'erreur. Au de-là de la confiance ou de l'importance qu'on peut accorder à FXCop, j'aimerai bien comprendre les risques. Que se passe-t-il si je créé une instance qui ne stope pas le script? Sera-t-elle perdue dans le GC?

De plus, je voudrais savoir comment vous vous y prenez pour la gestion d'erreurs personnalisées? Le jet d'une erreur dans une application web passe un peu inapparçue. Par contre dans un winform cela provoque un vilain plantage avec envoi de données à Bill.

Enfin, comment faites vous pour faire remonter une erreur sur l'interface utilisateur quand elle se produit dans une couche profonde (DAL) d'une architecture 3-Tiers? Faites-vous une verification systmatique de tous les parametres en entrée? Les parametres d'une application pouvant provenir de plusieurs sources (saisie, config, ...)

A+

[Guulh]

Je sais pas si ce oops signifie que t'as repéré ton erreur tout seul, mais créer une exception sans l'affecter à une référence ni la lancer ne sert à rien (et fxcop le voit bien).

[Immobilis]

Non, le oops est parce que j'ai posté un message en trop et je ne peux pas le supprimer.

Par contre, je ne suis pas vraiment d'accord sur ce que tu dis. J'ai bien repéré le message de FXCop disant: DoNotIgnoreMethodResults. Toutefois, cela ne sert pas à rien.
En effet, l'instance n'est pas réutilisée dans la suite du code c'est tout. Une erreur est jetée dans certains cas, dans d'autres non, mais un script est tout de mm executé.
On pourrait éventuellement remplacer cette instance pas une fonction static dans ce cas.
C'est peut-être la solution, je ne sais pas justement.

Si tu peux me dire comment tu personnalises ta gestion d'erreurs ce serait interessant.

A+

[StormimOn]

Comme l'a indiqué Guulh, une exception s'accompagne en général d'un throw ou bien on se la garde sous le coude pour une raison X ou Y, mais on ne fait pas un new dans le "vide" comme ça.

Si tu utilises ta classe BusinessException ainsi et en plus comme tu dis pouvoir éventuellement utiliser une méthode statique à la place, c'est que c'est un traitement que tu veux faire (journalisation des erreurs par exemple).

Une exception c'est juste un container d'information (un peu comme les EventArgs sont des containers d'information pour les événements), ça ne doit pas faire de traitements particuliers.

Faites-vous une vérification systématique de tous les paramètres en entrée ? Les paramètres d'une application pouvant provenir de plusieurs sources (saisie, config, ...)

Oui, sur toutes les méthodes que l'utilisateur pourra appeler c'est à dire les méthodes public, protected (l'utilisateur pouvant appeler la méthode de base depuis une classe dérivée) et même internal (discutable mais tellement pratique je trouve ^^). Dans ces cas là, je renvoie du ArgumentException, ArgumentOutOfRangeException, FileNotFoundException et j'en passe

Enfin, comment faites vous pour faire remonter une erreur sur l'interface utilisateur quand elle se produit dans une couche profonde (DAL) d'une architecture 3-Tiers ?

Je laisse l'exception remonter "naturellement" (pas de try/catch) en l'encapsulant dans une autre éventuellement (try/catch + throw) lors de la remontée, puisque plus on traverse de couches plus l'exception perd en général de son sens. Ensuite je la traite au niveau qui me semble le plus adapté (try / catch + affichage, log, ...). Maintenant je ne travaille pas sur des projets monstrueux, donc cela reste assez simple.

[Immobilis]

Comme l'a indiqué Guulh, une exception s'accompagne en général d'un throw ou bien on se la garde sous le coude pour une raison X ou Y

En général, comme tu dis. Combien d'entre nous font/ont fait des try catch silencieux? On peut très bien capter une erreur dans une DAL sans gravité tout en voulant la faire remonter à l'utilisateur, genre:

l'insertion des données en base n'a pas pu être réalisée car l'adresse email existe déjà

=> Sur une erreur de contrainte d'unicité. Tu vas pas faire un throw là-dessus. Est-ce que tu fais un aller retour la base pour savoir si l'email existe déjà avant de tenter l'insertion??

mais on ne fait pas un new dans le "vide" comme ça.

Quand on jette une erreur, il faut bien qu'elle soit récupérée quelque part. Un throw fait planter salement. Je veux éviter cela au maximum. Je vais pas non plus assigner mon instance puisque je n'en fait rien dans la suite du code.

Tout cela ne me dit pas vraiment comment vous gérez les erreurs personnalisées. Mettons que si une erreur survient, je veux que :

1. l'application continue de tourner.
2. l'utilisateur ait un message précis (pas une erreur est survenue le service technique est au courant...) lui expliquant ce qui s'est passé, ce qu'il doit faire pour que sa requete (pas seulement SQL) aboutisse.
3. Un mail soit envoyé à l'équipe technique
4. Une ligne soit inscrite dans un fichier de log
5. Un enregistrement soit enregistré en base

Franchement, je vois pas trop comment faire avec uniquement des throw... Un gestionnaire d'erreur n'est pas qu'un simple conteneur.
Et puis faire un new "comme ça" n'est pas si terrible en fait car même pour une méthode statique il y aura des instances de créées. Alors.

Merci pour vos réponses.

A+

[tomlev]

J'aurais plutôt fait quelque chose comme ça...

Code :

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

1
2
3
4
5
6
7
8
try
{
   (code...)
}
catch (DivideByZeroException ex)
{
    ErrorHandler.Handle(new BusinessException("this is a test", ex, BusinessExceptionLevel.Low));
}

Ca me semble plus propre de mettre les traitements dans une classe dédiée que dans une Exception qui, comme l'a dit StormimOn, est supposé être un simple container d'informations sur l'erreur.
Dans le ErrorHandler tu peux décider quoi faire de l'erreur : la logger, envoyer un mail, la relancer après l'avoir éventuellement enrichie d'informations utiles...

Que se passe-t-il si je créé une instance qui ne stope pas le script? Sera-t-elle perdue dans le GC?

S'il n'y a aucune référence dessus (ce qui sera le cas a priori), le GC finira par la ramasser... que veux-tu dire par "perdue" ?

EDIT: au fait, c'est quoi comme type d'appli ? Web, Windows ?

[Immobilis]

Ca me semble plus propre de mettre les traitements dans une classe dédiée que dans une Exception qui, comme l'a dit StormimOn, est supposé être un simple container d'informations sur l'erreur.
Dans le ErrorHandler tu peux décider quoi faire de l'erreur : la logger, envoyer un mail, la relancer après l'avoir éventuellement enrichie d'informations utiles...

Tout à fait.

que veux-tu dire par "perdue" ?

Vu que l'instance n'est pas assignée elle part dans le vent, elle ne peut pas être réutilisée.

EDIT: au fait, c'est quoi comme type d'appli ? Web, Windows ?

C'est pour une archi independante de l'interface (BO, BLL, DAL). Il y a bien une interface web au final, mais ce n'est pas à prendre en compte au niveau où je travaille il me semble car on doit pouvoir utiliser un winform.

Encore une fois comment faites vous?

A+

[tomlev]

Encore une fois comment faites vous?

Ben en pratique je ne fais pas vraiment de gestion "structurée" des erreurs... en général je mets des try/catch un peu à l'arrache, avec un MessageBox pour l'utilisateur.
Mais pour un site web c'est un peu moins simple à gérer, il faut quand même que la page finisse de se générer, d'où ma question sur le type d'appli

[Immobilis]

il faut quand même que la page finisse de se générer

Pas forcement. En cas d'erreur il y a une redirection sur une page spécifique qui affiche l'erreur et au besoin réalise un traitement.
Par contre, dans le cas d'un winform l'appli plante, se ferme, tout les données sont perdues et windows rapporte à Bill.

A+

[Guulh]

J'avais oublie que j'avais poste ici

En général, comme tu dis. Combien d'entre nous font/ont fait des try catch silencieux?

Faire un try catch silencieux, ok. Ca peux se justifier (meme si il vaut mieux logger, quand meme). Par contre, creer une exception et ne rien en faire, ca ne sert a rien. Et ca, FxCop le voit et te le dit.

Et puis faire un new "comme ça" n'est pas si terrible en fait car même pour une méthode statique il y aura des instances de créées. Alors.

Euh... Qu'entends-tu par "ce n'est pas si terrible" ? Ca empechera pas ton code de tourner, mais ca sert a rien. Comme si on mettait un new System.Windows.Forms.Form(); comme ca au milieu du code.

Quant a ce que tu dis sur les methode statiques : hein ? Justement, une methode statique n'a pas besoin d'une instance pour s'executer. C'est sa seule caracteristique, d'ailleurs.

Et "throw" ne fait pas planter. throw, ca permet juste a une couche de ton appli d'encpasuler un type d'exception qu'elle ne veut pas faire remonter aux couches superieures.
Donc oui, la couche graphique doit etre farcie de try catch, puisqu'elle n'a rien au dessus

Pour ce qui est du probleme de fond : gerer correctement les exceptions est difficile. Pour des applis serveur ou des assemblies que je fournis a des equipes tierces, j'encapsule toutes les exceptions propres a mes sources de donnees dans une exception typee, que je balance a mon client / l'utilsateur de mon assembly. Dans un projet type client graphique, en gros je chope toutes les excpetions qui m'arrivent des sources de donnees (via la couche DAL) dans une exception de DAL, qui contient un message que l'UI remonte dans une MessageBox.

[Immobilis]

Par contre, creer une exception et ne rien en faire, ca ne sert a rien. Et ca, FxCop le voit et te le dit.

Ben non, dans ce cas il ne voit pas car l'instance créé n'est pas un simple conteneur. Il y a un traitement qui envoi un email et en fonction du niveau de "menace" log seulement ou bien jette une erreur. Là où FXCop n'est pas content c'est que l'instance crée n'est pas réutilisée à la suite du code. Mais elle ne fait pas rien.

Quant a ce que tu dis sur les methode statiques : hein ? Justement, une methode statique n'a pas besoin d'une instance pour s'executer. C'est sa seule caracteristique, d'ailleurs.

Oui, je sais bien qu'on ne fait pas une instanciation d'une classe statique. Mais sauf erreur il y en a quand même une de créée à l'execution mais implicitement. Tombe-t-elle sur le tas ou dans la pile? Je ne sais plus.

Et "throw" ne fait pas planter. throw, ca permet juste a une couche de ton appli d'encpasuler un type d'exception qu'elle ne veut pas faire remonter aux couches superieures.

"catch" peut-être, mais chez moi "throw" stock l'execution (fait planter), fait planter une appli windows avec le message habituel où on te propose d'envoyer le bug à Bill.

Donc oui, la couche graphique doit etre farcie de try catch, puisqu'elle n'a rien au dessus

Mettons que tu ais une UI qui lorsque tu appuies sur le bouton fait appel à un process qui va telecharger un fichier, le lire, le compulser, le comparer avec des données en base et faire des mise à jour comme il faut. Est-ce que tu feras un "try catch" dessus? J'en doute car ça servira à rien si une erreur se produit. Sauf à faire un

Code :

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

1
2
3
4
5
6
7
8
9
 
try
{
       MonSuperProcessQuiFaitTout();
}
catch
{
       throw;
}

Ton erreur ne remontera pas si tu ne mets pas des try catch dans la bll, la dal et où tu veux. Or FXCop deconseil de capturer une "Exception". C'est reservé, pas assez détaillé.
Je crois que je vais m'orienter vers la suggession de tomlev

J'aurais plutôt fait quelque chose comme ça...

Code :

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

1
2
3
4
5
6
7
8
try
{
   (code...)
}
catch (DivideByZeroException ex)
{
    ErrorHandler.Handle(new BusinessException("this is a test", ex, BusinessExceptionLevel.Low));
}

Ca me semble plus propre de mettre les traitements dans une classe dédiée que dans une Exception qui, comme l'a dit StormimOn, est supposé être un simple container d'informations sur l'erreur.

Somme toute cela parait plus logique.

Pour ce qui est du probleme de fond : gerer correctement les exceptions est difficile. Pour des applis serveur ou des assemblies que je fournis a des equipes tierces, j'encapsule toutes les exceptions propres a mes sources de donnees dans une exception typee, que je balance a mon client / l'utilsateur de mon assembly. Dans un projet type client graphique, en gros je chope toutes les excpetions qui m'arrivent des sources de donnees (via la couche DAL) dans une exception de DAL, qui contient un message que l'UI remonte dans une MessageBox.

Comment fais-tu remonter une exception de la dal à l'UI? Un message du genre "votre saisie n'a pas pu etre enregistrée parce que ce pseudo existe déjà". Tu ferais une methode de bll du genre :

Code :

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

public bool VerifierPseudo(string pseudo)

Merci de votre participation

A+

[tomlev]

Oui, je sais bien qu'on ne fait pas une instanciation d'une classe statique. Mais sauf erreur il y en a quand même une de créée à l'execution mais implicitement. Tombe-t-elle sur le tas ou dans la pile? Je ne sais plus.

Non, aucune instance n'est créée, même implicitement, lors de l'utilisation de méthodes statiques.

"catch" peut-être, mais chez moi "throw" stock l'execution (fait planter), fait planter une appli windows avec le message habituel où on te propose d'envoyer le bug à Bill.

throw ne plante pas forcément l'appli, s'il y a un catch à un niveau supérieur de la pile pour l'intercepter... c'est un moyen simple de faire "remonter" les infos sur l'erreur des couches "profondes" de l'appli (DAL par exemple) vers l'UI.

Ton erreur ne remontera pas si tu ne mets pas des try catch dans la bll, la dal et où tu veux. Or FXCop deconseil de capturer une "Exception". C'est reservé, pas assez détaillé.

Ben c'est plutôt le contraire... en l'absence de try/catch, l'erreur remontera jusqu'à ce qu'elle soit interceptée par un catch...
Quant à l'utilisation d'un catch sur Exception, il parait que ce n'est pas une bonne pratique (ce qui ne m'empêche pas de le faire )... sans doute parce qu'idéalement il vaudrait mieux spécifier plus précisément le type d'exception que tu t'attends à avoir

Comment fais-tu remonter une exception de la dal à l'UI? Un message du genre "votre saisie n'a pas pu etre enregistrée parce que ce pseudo existe déjà". Tu ferais une methode de bll du genre :

Code :

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

public bool VerifierPseudo(string pseudo)

De toutes façons, il vaut mieux éviter de gérer ce genre de cas par des exceptions... c'est une erreur que tu peux anticiper, donc il faut tester avant que l'erreur ne se produise, plutôt que d'intercepter l'erreur après

[Immobilis]

Non, aucune instance n'est créée, même implicitement, lors de l'utilisation de méthodes statiques.

Pff, c'est un passage qui a du mal à rentrer chez moi...

Mais il faut tout de même que la classe soit "static", non? Dans le cas contraire, le compilateur ajoute un constructeur. L'appel d'une methode static dans une classe non static provoque-t-il un appel du constructeur?

A+

[SaumonAgile]

Bon alors :
- Une méthode standard s'exécute sur une instance d'une classe.
- Un constructeur sert à créer des instances d'une classe.
- Une méthode statique s'exécute sur la classe et non pas sur une instance.

une méthode static ne déclenche pas d'appel au constructeur.

[Guulh]

Mettons que tu ais une UI qui lorsque tu appuies sur le bouton fait appel à un process qui va telecharger un fichier, le lire, le compulser, le comparer avec des données en base et faire des mise à jour comme il faut. Est-ce que tu feras un "try catch" dessus? J'en doute car ça servira à rien si une erreur se produit.

Bien sur qu'il faut faire try catch dans un tel cas. Et si on chope une exception, on affiche un message d'erreur a l'utilisateur et on revient a un fonctionnement normal.

Comment fais-tu remonter une exception de la dal à l'UI? Un message du genre "votre saisie n'a pas pu etre enregistrée parce que ce pseudo existe déjà". Tu ferais une methode de bll du genre :

Bah dans ce cas, la DAL peut lancer (throw) une exception d'un type que tu auras defini, style "UtlisateurExisteDejaException", et l'appel dans ton UI a dal.CreerUser(...) est dans un try catch, avec une popup dans le catch.

Je vois pas bien ce qui te pose probleme