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

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre confirmé
    Profil pro
    Inscrit en
    Avril 2005
    Messages
    176
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Avril 2005
    Messages : 176
    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
    Avatar de tchize_
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Avril 2007
    Messages
    25 482
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : Belgique

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

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

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

    Informations forums :
    Inscription : Avril 2005
    Messages : 176
    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 313
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Novembre 2006
    Messages : 7 313
    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 extrêmement actif Avatar de Mister Nono
    Homme Profil pro
    Ingénieur Mathématiques et Informatique
    Inscrit en
    Septembre 2002
    Messages
    2 242
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    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 242
    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+

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

    Informations forums :
    Inscription : Avril 2005
    Messages : 176
    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
    Expert éminent
    Avatar de tchize_
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Avril 2007
    Messages
    25 482
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : Belgique

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

    Informations forums :
    Inscription : Avril 2007
    Messages : 25 482
    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.

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

    Informations forums :
    Inscription : Avril 2005
    Messages : 176
    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.

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

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

    Informations forums :
    Inscription : Avril 2007
    Messages : 25 482
    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

Discussions similaires

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

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