Throws Exception redondante / CheckStyle

Bonjour,

je viens d'installer CheckStyle avec un fichier de configuration "sun_checks.xml" afin de respecter au maximum les conventions java mais là j'ai une erreur qui m'interpelle.

J'ai une méthode qui throws différentes exceptions :
- des personnalisées afin d'afficher un message spécifique à l'utilisateur
- la générique pour traiter toutes les "autres" exceptions éventuelles.

Typiquement cela donne ceci :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

public void test() throws A, B, Exception {   }   [...] try { test(); } catch (A a) { showMessage(tata); } catch (B b) { showMessage(titi); } catch (Exception e) { showMessage(); }

---

sachant que A et B extends Exception.

CheckStyle ressort cela en erreur parce que A et B extends de Exception. Je ne comprends pas pourquoi c'est une erreur et non un warning.
Dois je en tenir compte, y a t il moyen de faire plus propre ?

Merci par avance pour vos réponses/suggestions.

Bonjour,

C'est quoi exactement l'intitulé de l'erreur ? Et le message ?

Sinon est ce que ça vient pas plutôt de ta méthode test qui

Code:

---

throws Exception

---

A mon sens c'est une mauvaise pratique de lancer une exception générique.

Dsl petit contre temps.
Oui cela vient bien d'une mauvaise pratique à priori.

J'avoue que je me paume vite avec les exceptions en java.
J'ai vu tout et n'importe quoi sur le net, du coup j'ai tendance à me poser des questions existentielles, et à ne plus savoir ce que je dois faire et quand.

Imaginons une problématique simple : je ne veux pas que l'utilisateur de mon appli web ne voit une exception lui péter au visage.

Pour ma part, j'avais tendance à gérer au plus haut niveau en mettant tjs des bloc try....catch, et dans les sous niveaux à mettre des throws les plus exhaustif possible.
Du coup, j'ai des throws avec des FileNotFound, JDomException etc.... mais afin de parer à toute exception par sécurité je mettais "Exception" de façon générique.
Voilà pourquoi CheckStyle n'apprécie pas, car finalement toutes les autres exceptions dérivant de Exception, il estime que c'est redondant.

Maintenant la bonne pratique est elle de ne mettre que les exceptions personnalisées dans les throws (io, filenotfound, jdom etc.) mais de catcher avec un simple catch(Exception e) si l'on ne souhaite pas mettre de message personnalisé au plus haut niveau ?
Ou bien de faire l'inverse, de ne pas mettre de throws personnalisé, juste throws Exception pour remonter tout type ?

Par avance merci !

La bonne pratique c'est:
1) tu ne remonte que les exceptions qui peuvent intéresser ton appelant. Quand tu as une méthode dont le boulot est "donne moi la liste des clients" qui doit parser un XML, ton appelant ne saura jamais quoi faire avec un FileNotFound ou un JDOMException. Renvoie lui un ClientsPasDisponibleException qui est chainé à la cause et déclare ta méthode comme "throws ClientsPasDisponibleException".
Bien sûr il ne faut pas être excessif non plus et enrober à chaque niveau. Il faut une juste mesure
2) c'est toujours une mauvaise idée de faire un catch(Exception e). Il ne faut catcher que les exceptions que tu sais gérer. Si tu ne sais pas gérer, laisse remonter. On ne traite pas de la même manière un fichier corrompu et un manque de mémoire disponible :)

Merci tchize pour ces précisions,

j'avais mis le sujet en résolu mais je le réouvre lol car je me pose encore des questions. Le roi des questions existentielles ! lol


Je reprends l'exemple du getClient ;)
si y a une lecture via du Xpath par exemple, tu as des JDOMException qui sont remontés par bon nombre de méthodes.
Du coup, si tu estime que ton appelant ne sait pas gérer cela, tu vas faire quoi ? des try....catch locaux dans le getClient pour traiter les JDOMException qui feraient des throw ClientsPasDisponibleException ?
car si tu ne fais rien, l'IDE va te rajouter le throws JDOMException de façon quasi automatique.

Et donc si je continue le raisonnement, c'est dans le throw ClientsPasDisponibleException que tu précisera une cause plus spécifique lié à la lecture XPath ?

Enfin, tu gère au plus niveau la remonté de ClientsPasDisponibleException.

Est ce que à ce petit jeu, tu ne risque pas d'avoir 3 tonnes d'exception personnalisées pour remonter aux appelants les erreurs qu'ils ne sont pas censés connaitre comme tu le disais....
Difficile donc d'avoir une juste mesure avec tous les IO, FileNotFound, JDOM que je traine en ayant pas mal de fichier et/ou fichier XML.


Est ce que c'est pour cela que dans bon nombre d'appli, on voit des BusinessException et des TechnicalException afin d'éviter de multiplier les exceptions personnalisées ? ici en l'occurence le traitement de la JDOM throw une Technical si je ne m'abuse.


Un gros merci à tous !

Citation:

---

Envoyé par Targan

si y a une lecture via du Xpath par exemple, tu as des JDOMException qui sont remontés par bon nombre de méthodes.
Du coup, si tu estime que ton appelant ne sait pas gérer cela, tu vas faire quoi ? des try....catch locaux dans le getClient pour traiter les JDOMException qui feraient des throw ClientsPasDisponibleException ?

---

Par exemple. Tu as plusieurs stratégies: soit tu enrobe le paquet:

Code:

---

1 2 3 4 5 6

try { // gros truc } catch (JDomException e){ log.warn("Hola pas sur parser le client",e); throw new ClientException("Clients non disponibles",e); }

---

soit tu fais plus fin:

Code:

---

1 2 3 4 5 6 7 8 9 10 11

try{ // parsing lecture fichier } catch (JDomException e){ log.warn("Hola fichier corrompu",e); throw new ClientException("Le fichier "+filename+" semble corrompu",e); }try{ // utilisation de xpaths divers } catch (JDomException e){ log.warn("La recherche xpath pose problème",e); throw new ClientException("Le fichier "+filename+" est soit incomplet, soit il n'y a pas de clients encore présent",e); }

---

Citation:

---

car si tu ne fais rien, l'IDE va te rajouter le throws JDOMException de façon quasi automatique.

---

normalement non. Par contre l'ide pourrait te dire "ca compile pas" et te proposer le throw dans les solutions possible. Je ne connais pas d'ide qui, de stock, fait tout remonter sans ton accord :)

Citation:

---

Et donc si je continue le raisonnement, c'est dans le throw ClientsPasDisponibleException que tu précisera une cause plus spécifique lié à la lecture XPath ?


Enfin, tu gère au plus niveau la remonté de ClientsPasDisponibleException.

---

oui

Citation:

---

Est ce que à ce petit jeu, tu ne risque pas d'avoir 3 tonnes d'exceptions personnalisées pour remonter aux appelants les erreurs qu'ils ne sont pas censés connaitre comme tu le disais....

---

Pour ça qu'il faut une juste mesure. Par exemple, l'api IO a un IOException générique + des spécifiques, mais elle ne joue pas à faire un FileIsReadOnlyException ou un FolderCanNotBeMovedException, les détails vont dans le message de l'exception et on envoi un simple IOException ;)

De la même manière, tu peux avoir une exception générique ClientException ou StorageException dont, peux être, tu dérive deux ou trois sous exceptions intéressantes et tu joue uniquement avec celles là. Finalement la question à te poser est
devrais-je faire un catch différencié entre ces deux cas dans l'appelant? oui -> deux exception. Non -> une seule exception.

La juste mesure. Pour un programme "simple" selon moi, tu ne devrais pas avoir besoin de plus de 3/4 exception. Pour mes codes complexes, j'ai souvent une seule exception par "zone de métier", ce qui m'amène à une dixaine d'exceptions à tout casser. Regarde JDom, il fait des trucs très complexe impliquant du parsing, des fichiers, des expressions régulières, etc. Le nombre d'exception différentes qu'il doit gérer est énorme. Et pourtant, il se contentent de 4 classes d'exceptions, toutes basée sur JDomException.

N'oublie pas non plus qu'une méthode qui déclare remonter 4 types d'exceptions différentes, c'est 4 fois le travail de catch() pour l'appelant à coder ;)

PS: il n'y a rien de mal non plus à remonter des IOException par exemple, si il est clair pour l'appelant que cette méthode est censé lire dans un fichier.

Citation:

---

Est ce que c'est pour cela que dans bon nombre d'appli, on voit des BusinessException et des TechnicalException afin d'éviter de multiplier les exceptions personnalisées ?

---

Oui, bien que je n'aime pas ces noms, trops générique. Je préfère des noms un peux plus explicites :p

Question : est ce que cela sous entendrait que des exceptions dites "techniques" seraient finalement remontées via une exception métier ?


Maintenant, je peux comprendre que si on réfléchit en terme de couche finalement une classe métier s'attend à une exception métier personnalisée, et que les exceptions techniques sont du côté DAO - Datas.
On garde ainsi une sorte d'indépendance des couches, seule l'exception personnalisée est à connaitre côté DAO pour la remonter.
Du coup, la classe métier a son exception métier remontée peu importe les raisons, et c'est finalement l'utilisateur final (ou un support) qui ira voir dans les log ce qu'il se passe et les vraies raisons de la levée de l'exception métier (une raison réellement métier, ou une raison plus technique) via la cause.


tchize_ Merci pour le temps passé à expliquer (à un noob) les bonnes pratiques :)

Citation:

---

Envoyé par Targan

Question : est ce que cela sous entendrait que des exceptions dites "techniques" seraient finalement remontées via une exception métier ?

---

Oui, et non :)

Si il est clair que ta méthode va lire des fichiers (genre la méthode s'appelle loadDatasFromFile), ca ne pose pas problème à mon avis de remonter un IOException, par exemple. Mais dans ton cas, remonter des JDomException n'est pas judicieux. Si demain ta classe préfère utiliser SAX, Stax ou Dom4j pour parser les fichiers, tu devra changer la signature de ta méthode métier alors que le changement est purement technique.