Transmis par: Sami actif Dimanche 27 Novembre 2005 à 22:44
La gestion des erreurs ! On entend ce terme fréquemment, il est souvent accompagné d'autres mots tels que exception, code de retour, erreur, handler, etc. Sebastien Andreo se propose dans cette article de clarifier ce vocabulaire et de présenter certaines règles d'utilisation des mécanismes de gestion d'erreur de la plateforme .Net. Vous verrez aussi comment mettre en place une gestion d'erreur générique.
Merci Sébastien !
Ca n'a rien à voir mais est-ce que quelqu'un connait le rapport entre Sébastien Andréo, Laurent Kempé, Kader Yildirim, Jean-Baptiste Evain et moi même ? A part bien sûr les fautes d'orthographe ;)
Sérieusement, quand on arrive à un tel niveau de complexité avec l'injection de dépendances (encore que, pour moi, ComponentModel ne constitue pas vraiment un Framework IoC pour les raisons invoquées ici, l'AOP devient vraiment obligatoire...
[Aucun sujet] par Anonyme actif 29 Nov 2005 à 18:29
Laisses tomber Sami, je suis sur le cul d'entendre ce genre de réponse de ta part.
Concernant AOP, ça me donne un air moqueur de l'entendre à chaque fois sur DNG parce que Personne ni même Tom n'est réellement capable de dire son exploitation dans la vie réelle, Production, Dév. . Ne me dites pas que c'est pour faire des Logs ou des Console.WriteLine, ...
J"aurai préféré entendre quelqu'un dire que AOP peut certainement induire la conception d'un Model, ... Tu m'entends Tom ? J'ai des cas intéressants qui s'appliquent dans le cadre de "dév." sur ce sujet. Ce qui me choquent de votre part à chaque fois que vous évoquez AOP, on a à chaque fois l'impression que l'utilisation de l'AOP se situe tjs à la fin d'un processe de dév. . Or, si on prend un peu de recul, on se rend compte, tisser, tisser, n'apporte rien si on ne peut pas débugger. Et surtout que ça n'a pas de sens de faire que dans l'intégration . Et du coup, on se pose la question, à qui réellement est réservé l'AOP ?
J'adhère la notion AOP mais à la manière que vous l'entendez.
Tiens tiens, Monsieur Anonymous est en fait Léon..
On m'avait dit que tu t'étais assagi, que tu avais grandi mais je m'aperçois au contraire que tu n'as pas changé. De toute façon il n'y a que toi pour nous pondre une telle usine à gaz. Personnellement je n'ai jamais compris un seul de tes commentaires, souvent plus proches d'aternoiements de schizophrène que de vraies ploblématiques techniques. Tu mélanges tout allégrement, ici en l'occurrence debug, model, process de dev, intégration (des sujets qui ne se situent pas sur le même plan)....
Bref, désolé, mais je te connais trop pour savoir qu'il n'existe point de débat avec toi. Alors je m'abstiens et passe mon tour.
Bon, je vais tenter de répondre point par point même si je trouve le commentaire mal placé: on parlait de gestion d'erreurs et tu embrayes spécifiquement sur l'AOP. Mais allons-y tout de même, comme si on était dans le forum AOP.
"Personne ni même Tom n'est réellement capable de dire son exploitation dans la vie réelle..."
Ben, je n'ai pas la science infuse, je ne revendique pas d'être le seul, le premier ni le meilleur à faire de l'AOP. Heureusement, il me reste beaucoup à apprendre. Comme tous les autres, j'essaie simplement d'apporter ma contribution à l'avancée du débat et de la recherche dans ce domaine. Un petit bouquin écrit voici un an et quelques mois, un tisseur d'aspects .NET qui prend tournure même s'il n'est pas du niveau "production" (malheureusement pour nous tous, il n'y en a aucun de ce niveau, et Microsoft n'est pas prêt de se mettre officiellement à l'AOP même si d'excellentes personnes ont les compétences requises chez l'éditeur), puis le PetShopAOP en début d'année. Voilà mon humble contribution.
Comment l'AOP est exploité dans la vie réelle? Que faut-il que je vous raconte?
- qu'on l'utilise pour détecter les fuites mémoires dans les applications Objet (Java ou .NET)
- que l'AOP bien sûr automatise les traces génériques
- que l'on peut concevoir des applications multi-couches avec inversion de dépendance aussi par l'AOP
- que l'AOP générique permet mieux que l'AOP classique d'implémenter certains design patterns dont le visiteur fortement typé sans introspection
- que certains chercheurs rapprochent l'AOP du recueil du besoin (cas d'utilisation) ou des finalités (goals) mais que le lien avec l'implémentation n'est pas encore très clair
- que certains systèmes d'exploitation (en C) gèrent la pagination mémoire par un aspect
- ... on pourrait en faire un bouquin ;-)
"...l'AOP se situe tjs à la fin d'un processe de dév..."
Etrange, pour ne reprendre que l'exemple du PetShop AOP, tous les éléments d'infrastructure technique sont tissés : distribution, gestion des ressources concernant la persistance, statistiques, traces, optimisations... Je n'ai pas vraiment l'impression que cela soit un détail ajouté en fin de développement, au contraire la conception détaillée (où se rejoignent la conception métier et le lien avec les frameworks techniques) se fait par tissage d'aspects. On est loin de la fin du dev.
"...tisser, n'apporte rien si on ne peut pas débugger..."
C'est marrant, j'ai fait très récemment un sondage chez des personnes d'horizons différents. Environ 20% des gens utilisent un débugger dans ceux que j'ai sondés. Les autres n'en éprouvent pas le besoin. Ils font pourtant du code de qualité, comme les 20% qui débuggent.
Donc c'est un débat intéressant, mais qu'il faudrait reprendre à part: débugger est-il utile, dans quel cas, pour qui, pour quelle partie d'application?
Après, concernant le tissage .NET et le débuggage, je botte en touche (on a déjà eu ce débat avec Bertrand): le format des fichiers PDB n'est pas normalisé / publié à l'ECMA (c'est d'ailleurs très dommage). Donc les tisseurs statiques .NET auront beaucoup de mal à générer les variables symboliques de débogage. Et, autre débat, comme je considère que le tissage dynamique via les dynamic proxies ne sont qu'un ersatz d'AOP (je ne parle pas du tissage au JIT qui est aussi puissant que le statique, seul son moment d'exécution est déporté), ce sera difficile. Mais pas impossible...
"J'adhère la notion AOP mais à la manière que vous l'entendez."
Bah, tant mieux: puisqu'il s'agit d'un domaine de recherche, où tout n'est pas vraiment déffriché (il reste à inventer une véritable modélisation orientée aspects, des outils pour le traduire en programmation orientée aspects, il nous faudra un certain nombre de patterns et d'anti-patterns, et enfin que les outils et les Hommes s'améliorent dans ce domaine). Donc plus nous aurons de points de vue, de débats, d'outils
Si à chaque fois que je fais un commentaire, et qu'on juge que c'est mal placé, merci !
Mon lien ciblé le sujet de la gestion d'Exception en question. Je n'étais pas là à promouvoir que le ComponentModel sait faire de IOC.
Si à chaque fois que nous lisons un article de fond, on doit tous les prendre au premier degré, ... désolé, cela ne fait pas partie de ma culture.
Cet article soulevait la problèmatique du Try Catch et on sait tous à quel point la remontée d'exception est couteuse, qu'elle aborde une autre façon de gérer les Exceptions métiers ayant un couplable faible par le biais d'un ComponentModel.
Bref, comme tu dis Sami, je n'ai pas changé et réciproquement. Ton ego est tellement fort qu'il est difficile pour toi de penser instant que parfois tu fais des erreurs. C'est humain et on le fait tous.
Désolé si mes commentaires sont en anonyme, je n'y peux rien si c'est votre site qui fait ça. Si je ne me suis pas connecté, je ne pourrai pas écrire ces posts et du moins signé "Léon Andrianarivony" en clair.
Tom : Envois moi juste un mail sur and.leo@laposte.net et je te fais un forward avec plaisir de ceux que je souhaite faire avec l'AOP. Du moins, l'exploiter à des fins subtiles.
Ton ego est tellement fort qu'il est difficile pour toi de penser instant que parfois tu fais des erreurs. C'est humain et on le fait tous.
Je vais te rassurer alors, des erreurs j'en fais tous les jours. La preuve j'ai répondu sincèrement (comme on le fait souvent sur DNG) à ton commentaire sans savoir que c'était toi. Et j'aurais mieux fait de m'abstenir :-).
Je te fais un forward avec plaisir de ceux que je souhaite faire avec l'AOP. Du moins, l'exploiter à des fins subtiles.
public abstract class ContextedContainer : Container, IContextedContainer
where T : IContainer
where C : IComponent
where X : ContainerContext, new()
where S : ISite, new()
where K : new()
...
Je pense que ce genre d'article est très important car il rappelle ou attire l'attention sur des pratiques que les développeurs ont tendance à négliger.
Deux remarques minimes :
- il est important d'utiliser le construteur avec le paramètre "inner" qui permet de conserver trace de l'exception d'origine, ce qui pourra alors être renseigné dans un fichier de log et permettra de mieux comprendre la cause d'exceptions inattendues.
- Le code suivant :
car on ne protège une ressource que si elle a été allouée. Ici, on ne peut à l'évidence fermer le FileStream que s'il a été créé et qu'après l'opération d'affectation à la variable "stream".
Re: Un guide de bonnes pratiques pour gérer les erreurs en .NET
par Amethyste actif 28 Nov 2005 à 19:01 (Profil Utilisateur | Envoyer un message)
Article très intéressant.
Juste 1 remarque:
Lorsque tu dis une erreur doit dériver de System.Exception, pas tout à fait. MS recommande plutôt System.ApplicationException afin de pouvoir éventuellement distinguer les erreurs du framework des erreurs applicatives.
Ca peut être intéressant justement si on fait des log.
oui tu as raison c'est plutot ApplicationException mais je m'etais un peu couvert en ecrivant "Toujours se dériver de System.Exception ou d'une des autres exceptions de base..." :-)
Re: Un guide de bonnes pratiques pour gérer les erreurs en .NET
par smacchia_patrick actif 28 Nov 2005 à 20:41 (Profil Utilisateur | Envoyer un message)
Effectivement trés bon article. Cette mouvance de guidelines do/consider/avoid/don't avec des conseils concis me parait bénéfique pour la communauté.
Allez hop, un ptit extrait de Pratique2 sur le sujet:
(...)Le principe de base est qu’une application qui fonctionne en mode normal ne devrait pas lancer d’exception. Cela repousse le problème sur la définition des situations anormales. Il y en a de trois types :
Celles qui surviennent à cause d’un problème d’environnement d’exécution et qui peuvent être réglées par une modification de cet environnement (absence d’un fichier de configuration, mauvais mot de passe, réseau indisponible, permissions restreintes etc). On parle d’exception applicative.
Celles qui surviennent à cause d’un problème d’environnement d’exécution qui ne peut être résolu. Par exemple, les applications gourmandes en mémoire telles que SQL Server 2005 peuvent être limitées par les 2 ou 3Go d’espace utilisateur d’un processus Windows 32 bits. On parle d’exception asynchrone du fait qu’une telle exception ne dépend pas de la sémantique de la portion de code qui l’a levé.
Celles qui surviennent à cause d’un bug et qui ne peuvent être réglées que par une nouvelle version corrigeant ce bug.
