IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Java Discussion :

Stratégies de gestion des exceptions


Sujet :

Java

  1. #1
    Membre régulier
    Profil pro
    Inscrit en
    Avril 2005
    Messages
    176
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Avril 2005
    Messages : 176
    Points : 124
    Points
    124
    Par défaut Stratégies de gestion des exceptions
    Bonjour tout le monde,

    Je lance une petite discussions au sujet des différentes stratégies de gestion des exceptions qui peuvent être mises en place en Java.
    C'est une problématique que je rencontre assez souvent.
    J'aurai aimé avoir votre retour là-dessus et que vous veniez nous présenter les stratégies que vous avez vous-même mises en place.

    Merci de vos contributions.

    Pierre.

  2. #2
    Expert éminent sénior
    Avatar de tchize_
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Avril 2007
    Messages
    25 481
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : Belgique

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Avril 2007
    Messages : 25 481
    Points : 48 806
    Points
    48 806
    Par défaut
    qu'est-ce que tu entends par stratégie de gestion des exceptions?

  3. #3
    Membre régulier
    Profil pro
    Inscrit en
    Avril 2005
    Messages
    176
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Avril 2005
    Messages : 176
    Points : 124
    Points
    124
    Par défaut
    Ce que j'entends pas stratégie de gestion des exceptions est simplement lorsque tu développes une application et que tu rencontres une exception à gérer comment le fais-tu?
    Qu'est ce qui fait que tu vas gérer l'exception immédiatement et qu'est ce qui fait que tu vas transmettre l'exception plus haut à ta méthode appelante (utilisation de throws dans la signature)?
    Il y a également des stratégies auxquelles tu peux avoir pensé lors de la conception de ton application. Par exemple, toutes les classes d'exceptions propres à mon application hériteront d'une classe exception mère avec des fonctions prédéfini pour qu'elles respectent toutes les mêmes normes.
    etc...

    Tout ce qui peut constituer une stratégie, une norme, une bonne pratique...

    Dis-moi si cela est plus clair avec ce complément d'information.

  4. #4
    Modérateur
    Avatar de OButterlin
    Homme Profil pro
    Inscrit en
    Novembre 2006
    Messages
    7 310
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Novembre 2006
    Messages : 7 310
    Points : 9 522
    Points
    9 522
    Billets dans le blog
    1
    Par défaut
    (de mon point de vue)

    Les exceptions sont gérées à l'endroit où ça a un sens, trop de catch tue le catch et peut masquer des erreurs

    Prenons le cas d'une conversion chaîne en entier.
    Dans la plupart des cas, tu vas mettre un try catch à l'endroit où tu convertis avec éventuellement une valeur par défaut si la conversion échoue.
    Dans une classe de conversion JSF (par example), tu pourrais être amené à vouloir propager l'erreur de conversion... Tout ça pour dire que ce n'est pas évident d'établir des règles inscrites dans le marbre pour déterminer l'endroit où tu propages de l'endroit où tu catch...

    Pour ce qui est de la structure des exceptions, j'utilise une exception nommée ValidationException qui contient une liste de CauseException pour faire et propager mes contrôles dans la couche métier.
    Ce serait dommage de présenter à l'utilisateur les erreurs l'une après l'autre...

    J'ai également créé une classe utilitaire qui convertit les causes en messages lisibles par l'utilisateur (en tenant compte de la Locale et des fichiers .properties bien sûr).

    Du coup, le principe est le suivant : le contrôleur appelle la couche métier (EJB) et catch l'exception et la passe à la classe utilitaire.
    N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  5. #5
    Membre chevronné Avatar de Mister Nono
    Homme Profil pro
    Ingénieur Mathématiques et Informatique
    Inscrit en
    Septembre 2002
    Messages
    2 232
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur Mathématiques et Informatique
    Secteur : Santé

    Informations forums :
    Inscription : Septembre 2002
    Messages : 2 232
    Points : 1 891
    Points
    1 891
    Par défaut
    Bonjour,

    Une méthodologie que j'ai adopté et qui fonctionne bien dans de très nombreux cas :

    Quand une méthode soulève une exception, je la gère dans cette méthode car c'est là que l'on sait ce qui s'est passé et pourquoi.

    Maintenant il n'est pas pertinent ou alors pertinent pour la méthode appelante qu'une exception ait été traitée. Comme la méthode qui gère sa propre exception ne le sait pas, je fais un "throw" de cette exception à la méthode appelante qui en fait que qu'elle veut : par exemple, elle prévient l'utilisation d'un soucis ou alors renvoi l'objet demandé quand même suivant le contexte...

    Cela permet de faire une séparation entre la gestion de l'exception au plus tôt et ce que l'on fait quand une exception est traitée : une séparation de couche comme le préconise MVC. Maintenant si l'interface utilisateur doit changer, la partie métier et la partie modèle gèreront toujours leurs exceptions en interne.

    A+
    La connaissance ne sert que si elle est partagée.
    http://ms2i.net

  6. #6
    Membre régulier
    Profil pro
    Inscrit en
    Avril 2005
    Messages
    176
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Avril 2005
    Messages : 176
    Points : 124
    Points
    124
    Par défaut
    Merci pour vos retours.

    Citation Envoyé par Mister Nono Voir le message

    Maintenant il n'est pas pertinent ou alors pertinent pour la méthode appelante qu'une exception ait été traitée. Comme la méthode qui gère sa propre exception ne le sait pas, je fais un "throw" de cette exception à la méthode appelante qui en fait que qu'elle veut : par exemple, elle prévient l'utilisation d'un soucis ou alors renvoi l'objet demandé quand même suivant le contexte...
    Je ne suis pas sur d'avoir bien compris ce que tu veux dire. Je me permet de le reformuler.
    Lorsque tu as traité une exception dans une méthode tu génères une nouvelle exception que tu transmets à la méthode appelante pour qu'elle soit informé qu'il y a eu une erreur.
    Est-ce bien ceci que tu voulais dire?

    Bonne journée.

  7. #7
    Modérateur
    Avatar de OButterlin
    Homme Profil pro
    Inscrit en
    Novembre 2006
    Messages
    7 310
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Novembre 2006
    Messages : 7 310
    Points : 9 522
    Points
    9 522
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par Anubis Voir le message
    Lorsque tu as traité une exception dans une méthode tu génères une nouvelle exception que tu transmets à la méthode appelante pour qu'elle soit informé qu'il y a eu une erreur.
    Non, il traite l'exception dans le catch et la renvoie (la même)
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    try
    {
       ...
       un truc qui lance une exception
       ...
    }
    catch (Exception e)
    {
       System.out.print("J'ai une erreur dans la méthode blablabla... : " + e.toString());
       throw e;
    }
    N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  8. #8
    Membre régulier
    Profil pro
    Inscrit en
    Avril 2005
    Messages
    176
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Avril 2005
    Messages : 176
    Points : 124
    Points
    124
    Par défaut
    Citation Envoyé par OButterlin Voir le message
    Non, il traite l'exception dans le catch et la renvoie (la même)
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    try
    {
       ...
       un truc qui lance une exception
       ...
    }
    catch (Exception e)
    {
       System.out.print("J'ai une erreur dans la méthode blablabla... : " + e.toString());
       throw e;
    }
    C'est toujours dans le but d'informer la méthode appelante qu'une exception à eu lieu même si elle a été géré par la méthode appelé. Merci pour cette réponse, je vois mieux comment c'est techniquement fait.

  9. #9
    Expert éminent sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    Avril 2002
    Messages
    13 938
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java/Web
    Secteur : Transports

    Informations forums :
    Inscription : Avril 2002
    Messages : 13 938
    Points : 23 190
    Points
    23 190
    Billets dans le blog
    1
    Par défaut
    Salut,


    Pour moi on ne devrait traiter une exception uniquement dans le cas où l'on sait qu'elle peut se produire ET que l'on sait comment la traiter.
    Sinon il vaut mieux la laisser remonter...


    Le tout couplé à un système de récupération des exceptions non-traité afin d'indiquer le problème a l'utilisateur et de remonter les infos de debug à l'équipe de développement (via un UncaughtExceptionHandler ou autre selon l'architecture).



    Le problème c'est que les "checked-exceptions" de Java n'aide pas vraiment, en nous obligeant soit à les traiter (même si on ne sait qu'en faire) soit à les faire remonter explicitement (ce qui n'est pas toujours possible).
    Du coup on est souvent obligé des les catcher pour les encapsuler dans une RuntimeException...


    a++

  10. #10
    Modérateur
    Avatar de OButterlin
    Homme Profil pro
    Inscrit en
    Novembre 2006
    Messages
    7 310
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Novembre 2006
    Messages : 7 310
    Points : 9 522
    Points
    9 522
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par adiGuba Voir le message
    Pour moi on ne devrait traiter une exception uniquement dans le cas où l'on sait qu'elle peut se produire ET que l'on sait comment la traiter.
    Sinon il vaut mieux la laisser remonter...
    C'est effectivement une bonne pratique, mais le problème vient parfois du fait que la façon de traiter dépend de l'endroit où elle se déclenche.
    Je reformule ce que tu disais en :

    on devrait traiter une exception uniquement dans le cas où l'on sait qu'elle peut se produire ET que l'on sait comment la traiter de façon exhaustive

    Tu es d'accord avec le postulat ou tu voyais autre chose ?

    Pour la problèmatique "locale" du contexte de l'erreur, tu aurais une idée ?
    N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  11. #11
    Expert éminent sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    Avril 2002
    Messages
    13 938
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java/Web
    Secteur : Transports

    Informations forums :
    Inscription : Avril 2002
    Messages : 13 938
    Points : 23 190
    Points
    23 190
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par OButterlin Voir le message
    Pour la problèmatique "locale" du contexte de l'erreur, tu aurais une idée ?
    Laisser remonter l'exception est amplement suffisant : on arrête tout.
    Dans la majorité des cas il n'y a rien de mieux à faire...

    Bien sûr il faut gérer proprement les ressources en les fermant proprement, et on pourrait mettre en place des "rollbacks" selon le cas, mais je ne considère pas cela comme une gestion de l'exception à proprement parler.


    a++

  12. #12
    Modérateur
    Avatar de OButterlin
    Homme Profil pro
    Inscrit en
    Novembre 2006
    Messages
    7 310
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Novembre 2006
    Messages : 7 310
    Points : 9 522
    Points
    9 522
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par adiGuba Voir le message
    Laisser remonter l'exception est amplement suffisant : on arrête tout.
    Dans la majorité des cas il n'y a rien de mieux à faire...
    En pratique, c'est ce que je fais... mais j'aurais bien aimé un système adaptatif.

    Bon, c'est certainement un faux problème, on peut faire plusieurs méthodes utilitaires pour centraliser des traitements/comportements différents
    N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  13. #13
    Membre régulier
    Profil pro
    Inscrit en
    Avril 2005
    Messages
    176
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Avril 2005
    Messages : 176
    Points : 124
    Points
    124
    Par défaut
    Citation Envoyé par adiGuba Voir le message
    Salut,


    Pour moi on ne devrait traiter une exception uniquement dans le cas où l'on sait qu'elle peut se produire ET que l'on sait comment la traiter.
    Sinon il vaut mieux la laisser remonter...
    +
    Mais si un exception qui ne semblait pas possible est remonté cela peut-être considéré comme un bug et que l'application n'est pas robuste.
    Est-ce que toutes les exceptions qui peuvent être remonté ne devrait pas être prise en compte? Car si le développeur de la fonction lui fait remonter une exception c'est qu'elle peut arriver et donc qu'elle doit être traité, non?
    Qu'en pensez-vous?

    Cependant, j'aime bien l'idée d'un UncaughtExceptionHandler, qui permet de ne pas laisser une exception exploser littéralement à la tête de l'utilisateur.

    A plus,

    Pierre.

  14. #14
    Membre chevronné
    Avatar de professeur shadoko
    Homme Profil pro
    retraité nostalgique Java SE
    Inscrit en
    Juillet 2006
    Messages
    1 257
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 75
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : retraité nostalgique Java SE

    Informations forums :
    Inscription : Juillet 2006
    Messages : 1 257
    Points : 1 855
    Points
    1 855
    Par défaut
    Citation Envoyé par adiGuba Voir le message
    Le problème c'est que les "checked-exceptions" de Java n'aide pas vraiment, en nous obligeant soit à les traiter (même si on ne sait qu'en faire) soit à les faire remonter explicitement (ce qui n'est pas toujours possible).
    Du coup on est souvent obligé des les catcher pour les encapsuler dans une RuntimeException...
    Hmmm... là il est difficile (pour moi) d'appréhender le problème dans sa généralité.
    En principe on pourrait classifier les choses dans deux catégories:
    - les exceptions "normales " relevant du fonctionnement "normal" de l'application. exemple: on dit que si on veut retirer trop d'argent sur un compte on claque une ExceptionDecouvert et là les exceptions controlées ("checked") sont du pain beni.
    - les exceptions relevant d'un comportement anormal : bug -> NullPointerException; violation de contrat -> IllegalArgumentException etc... donc RuntimeException

    En réalité il y a une "zone grise" qui enquiquine beaucoup c'est quand on a un problème de "service" genre IOException ... un défaut de service est-il un problème métier ou un bug? ah ... il parait que ça pose bien des problèmes de gestion d'exception (ça ne m'en a jamais posé mais je ne jurerai pas que ça ne m'arrivera pas un jour)... mais , pour commencer, la classification en deux catégories bien distinctes permet d'éclaircir les idées (même si dans certains cas on se retrouve avec des codes très génériques qui font throws Exception ... ce qui est un peu contradictoire avec quelques bons principes... mais bon ça ne m'empêche pas de dormir)
    J'ai des principes: je peux toujours trouver une bonne raison pour les contredire .... mais j'ai des principes!
    (mon excellent bouquin sur Java : https://eska-publishing.com/fr/livre...822407076.html)

  15. #15
    Membre habitué
    Profil pro
    Inscrit en
    Décembre 2009
    Messages
    173
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2009
    Messages : 173
    Points : 187
    Points
    187
    Par défaut
    Sur les projets sur lesquels j'ai été, voici ce qui était fait:
    - Quand on utilise une méthode qui peut par exemple lever une IOException on l'entoure d'un try-catch. Dans le catch on logue une erreur et on throw une de nos propres exception (liée à la fonctionnalité de l'application) avec une catégorie qui correspond à l'endroit où s'est produit l'exception. Il y a un message et une solution possible par catégorie.
    - Notre propre exception est remontée jusqu'au client afin qu'il y ait l'affichage du message correspondant (ex: l'import du fichier XML n'a pas marché et qu'il faut vérifier son contenu, qu'il est bien formé).
    Diplomes: DUT informatique et Master 2 MIAGE.
    Développeur Java/J2EE (principalement), .NET (niveau scolaire mais je compte m'améliorer ) et Web (HTML, PHP...).

  16. #16
    Expert éminent sénior
    Avatar de tchize_
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Avril 2007
    Messages
    25 481
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : Belgique

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Avril 2007
    Messages : 25 481
    Points : 48 806
    Points
    48 806
    Par défaut
    Citation Envoyé par Anubis Voir le message
    Ce que j'entends pas stratégie de gestion des exceptions est simplement lorsque tu développes une application et que tu rencontres une exception à gérer comment le fais-tu?
    Qu'est ce qui fait que tu vas gérer l'exception immédiatement et qu'est ce qui fait que tu vas transmettre l'exception plus haut à ta méthode appelante (utilisation de throws dans la signature)?
    Alors je ne sais pas si on peux vraiment parler de stratégie, c'est souvent de la décision cas par cas:

    Deux questions fondamentales à se poser sur l'exception: Est-ce que je sais en faire quelque chose? Est-ce qu'il est important d'en avertir l'appelant?

    Si je sais en faire quelque chose (de cohérent j'entends pas juste log.error("Houla c'est le bordel ici")), je le fait.

    Exemple: on me demande de contacter le LDAP pour retourner une liste d'utilisateur, le LDAP est mort, je suis capable de me rabattre sur le LDAP de backup, je le fait

    Si je ne sais rien en faire, je ne joue pas à l'apprentit magicien

    Exemple: on me demande de stocker un objet utilisateur sur une base de donnée, la connection avec le serveur de base de données est coupée, je vois pas trop quelle solution je pourrais apporter => on arrête les frais et on remonte.

    Même si j'ai pu traiter le problème, si il est important d'avertir l'appelant, il est souvent préférable de lui lancer une exception plutôt que de lui retourner une valeur clé indiquant erreur. Car l'exception il devra en faire quelque chose, mais on a vite oublié que ça peut retourner erreur et juste balancer ça dans je ne sais quelle base de données comme une vraie valeur

    Exemple: je dois télécharger un fichier .ODT sur une URL pour le convertir en PDF et le stocker sur le disque. L'URL me renvoie une IOException. Je peux traiter cette exception: fermeture du stream, arrêt de l'outil de convertion évenetuel, pas de création du PDF. Mais l'appelant a besoin de savoir que ca n'a pas été possible => je lui balance une exception de mon cru du style "ConversionFailed" parce que l'appelant il se fous de savoir que c'est du à un IOException ou un bug du converter.

  17. #17
    Expert éminent sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    Avril 2002
    Messages
    13 938
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java/Web
    Secteur : Transports

    Informations forums :
    Inscription : Avril 2002
    Messages : 13 938
    Points : 23 190
    Points
    23 190
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par Anubis Voir le message
    Mais si un exception qui ne semblait pas possible est remonté cela peut-être considéré comme un bug et que l'application n'est pas robuste.
    Raison de plus de remonter l'exception : cela permettra in fine d'avoir un rapport de bug.

    Si tu traites l'exception sans savoir quoi en faire, tu risques de faire n'importe quoi ce qui engendrera in fine une autre exception...

    Citation Envoyé par Anubis Voir le message
    Est-ce que toutes les exceptions qui peuvent être remonté ne devrait pas être prise en compte? Car si le développeur de la fonction lui fait remonter une exception c'est qu'elle peut arriver et donc qu'elle doit être traité, non?
    Cela dépend de beaucoup de chose...
    La quasi-totalité des méthodes peuvent remonter un NullPointerException. Est-ce que tu as des try/catch partout pour cela ???

    Si tu ne sais pas comment traiter une exception, il n'y a pas de raison de le faire.
    Autant la laisser remonter à l’appelant, qui se chargera de la traiter (ou pas).

    Quitte à faire planter le programme/thread... mais un exception handler te permettra de récupérer les infos utile !


    Citation Envoyé par professeur shadoko Voir le message
    Hmmm... là il est difficile (pour moi) d'appréhender le problème dans sa généralité.
    En principe on pourrait classifier les choses dans deux catégories:
    - les exceptions "normales " relevant du fonctionnement "normal" de l'application. exemple: on dit que si on veut retirer trop d'argent sur un compte on claque une ExceptionDecouvert et là les exceptions controlées ("checked") sont du pain beni.
    - les exceptions relevant d'un comportement anormal : bug -> NullPointerException; violation de contrat -> IllegalArgumentException etc... donc RuntimeException
    Le problème c'est que les checked-exception imposent ces catégorie sur le type de l'exception, alors que cette "zone grise" peut être assez large et qu'une même exception peut appartenir à une ou l'autre de ces catégorie, parfois même au sein d'une même méthode.

    A l'inverse des unchecked-exceptions n'imposent rien, et l'on peut donc passer de l'une à l'autre selon notre besoin.


    Sans compter que les checked-exception s'adapte mal et imposent de modifier les signatures, ce qui n'est pas forcément souhaitable ni possible.



    a++

  18. #18
    Membre régulier
    Profil pro
    Inscrit en
    Avril 2005
    Messages
    176
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Avril 2005
    Messages : 176
    Points : 124
    Points
    124
    Par défaut
    Citation Envoyé par tchize_ Voir le message
    Exemple: je dois télécharger un fichier .ODT sur une URL pour le convertir en PDF et le stocker sur le disque. L'URL me renvoie une IOException. Je peux traiter cette exception: fermeture du stream, arrêt de l'outil de convertion évenetuel, pas de création du PDF. Mais l'appelant a besoin de savoir que ca n'a pas été possible => je lui balance une exception de mon cru du style "ConversionFailed" parce que l'appelant il se fous de savoir que c'est du à un IOException ou un bug du converter.
    Quand tu dis qu'il n'est pas important pour l'appelant de savoir que l'erreur du converter est du à une IOException ou un bug, je ne suis pas tout à fait d'accord. Afin de pouvoir informer l'utilisateur de manière pertinente il faut bien que l'application connaisse d'une manière ou d'une autre ce qui s'est passé.
    Je trouve que c'est une très bonne idée d'utiliser une Exception du type "ConversionFailed" pour les erreurs concernant uniquement le Converter. Cela permet à l'appelant de ne pas avoir à gérer une multitude d'exceptions différentes qui peuvent être remonté par la méthode appelé. Cependant, je pense que cette exception générique doit encapsuler l'exception d'origine (ici, IOException) afin de ne pas perdre d'informations qui peuvent s'avérer précieuse pour l'utilisateur voire la personne en charge de la maintenance pour trouver une solution au problème.

  19. #19
    Expert éminent sénior
    Avatar de tchize_
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Avril 2007
    Messages
    25 481
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : Belgique

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Avril 2007
    Messages : 25 481
    Points : 48 806
    Points
    48 806
    Par défaut
    Citation Envoyé par Anubis Voir le message
    Quand tu dis qu'il n'est pas important pour l'appelant de savoir que l'erreur du converter est du à une IOException ou un bug, je ne suis pas tout à fait d'accord. Afin de pouvoir informer l'utilisateur de manière pertinente il faut bien que l'application connaisse d'une manière ou d'une autre ce qui s'est passé.
    On est d'accord mais je peux très bien mettre cette information dans mon exception custom. Par exemple en chainant l'exception. Je peux aussi mettre ça dans les logs, ça fait partie du traitement local.

    L'appelant (au sens de la méthode) se fous de savoir que le problème est une interruption de flux, un connection reset by peer, ou autre. L'information dont il a besoin c'est "le document n'est pas accessible". Eventuellement si on est sur un outil technique, "le document n'est pas accessible: http 503".

    Quand je dis que l'appelant se fous de savoir que c'est une IOException j'entends pas là qu'il est inutile de la remonter. Aujourd'hui c'est une IOException parce que j'utilise les apis type URL / openConnection, demain ce sera une StreamException parce que j'aurais switché à un autre outils qui renvoie ce genre d'exception, etc. L'IOException est liée au choix technique d'utiliser des libriarie qui remontent ça. L'appelant s'en contre fou. Il dois savoir que la conversion n'a pas eu lieu et bien sur pourquoi (message).



    Quand au ConversionFailed il peux se décliner autant que tu veux:

    ConversionFailed -> ConversionReaderFailed, ConversionWriterFailed, etc.

    On est sur de l'exemple en une ligne là dans ce que je donnais

  20. #20
    Membre régulier
    Profil pro
    Inscrit en
    Avril 2005
    Messages
    176
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Avril 2005
    Messages : 176
    Points : 124
    Points
    124
    Par défaut
    Citation Envoyé par tchize_ Voir le message
    On est d'accord mais je peux très bien mettre cette information dans mon exception custom. Par exemple en chainant l'exception. Je peux aussi mettre ça dans les logs, ça fait partie du traitement local.

    L'appelant (au sens de la méthode) se fous de savoir que le problème est une interruption de flux, un connection reset by peer, ou autre. L'information dont il a besoin c'est "le document n'est pas accessible". Eventuellement si on est sur un outil technique, "le document n'est pas accessible: http 503".

    Quand je dis que l'appelant se fous de savoir que c'est une IOException j'entends pas là qu'il est inutile de la remonter. Aujourd'hui c'est une IOException parce que j'utilise les apis type URL / openConnection, demain ce sera une StreamException parce que j'aurais switché à un autre outils qui renvoie ce genre d'exception, etc. L'IOException est liée au choix technique d'utiliser des libriarie qui remontent ça. L'appelant s'en contre fou. Il dois savoir que la conversion n'a pas eu lieu et bien sur pourquoi (message).



    Quand au ConversionFailed il peux se décliner autant que tu veux:

    ConversionFailed -> ConversionReaderFailed, ConversionWriterFailed, etc.

    On est sur de l'exemple en une ligne là dans ce que je donnais
    Je ne l'avais pas compris ainsi. J'avais une autre vision de ta stratégie.
    Je voyais la chose ainsi:

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
     
    public void called() throws calledException{
        try{
            ...
        }
        catch(ExceptionHappened EH){
            throw new CalledException("message", EH);
        }
    }
    avec
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
     
    public void caller(){
        try{
            called();
        }
        catch(calledException){
            manage the exception.
        }
    }
    Ainsi l'appelant peut toujours accéder à l'historique de l'exception.

Discussions similaires

  1. [EJB] [Stratégie] Gestion des exceptions
    Par nelob dans le forum Java EE
    Réponses: 0
    Dernier message: 15/05/2009, 16h40
  2. [ORACLE 9i] Gestion des exceptions
    Par sygale dans le forum SQL
    Réponses: 6
    Dernier message: 19/08/2004, 16h06
  3. Gestion des exception (EOleException)
    Par shurized dans le forum Bases de données
    Réponses: 5
    Dernier message: 30/06/2004, 18h25
  4. [XMLRAD] gestion des exceptions
    Par pram dans le forum XMLRAD
    Réponses: 2
    Dernier message: 28/01/2003, 18h48
  5. c: gestion des exceptions
    Par vince_lille dans le forum C
    Réponses: 7
    Dernier message: 05/06/2002, 15h11

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo