comment gérer les RuntimeException ?

Bonjour à tous,

j'ai lu sur le net, et je remarque grâce à mon compilo, que les RuntimeException ne doivent pas forcément être traitées. J'ai lu également que ce sont des exceptions qui ne devraient pas se produire.

J'en déduis donc qu'il faut rajouter des instructions de test pour que l'exception ne se produise pas, on est d'accord ?

Par exemple, pour un Integer.parseInt(String s), il faut tester que s a bien un format numérique, on est toujours d'accord ?

Juste pour avoir un exemple, comment testeriez-vous ça proprement ? (j'avais pensé à quelque chose genre s.matches("{-}?[0-9]+")...

Merci à vous de me dire si j'ai raison à propos de la gestion de l'exception :)
a+

Citation:

---

Envoyé par _LittleFlea_

j'ai lu sur le net, et je remarque grâce à mon compilo, que les RuntimeException ne doivent pas forcément être traitées. J'ai lu également que ce sont des exceptions qui ne devraient pas se produire.

---

En théorie oui... Plus précisément, qu'elles dénotent une erreur du programmeur (a utilisé un paramètre invalide, a laissé s'installer un état incorrect, a déréférencé un pointeur null, a accédé à un tableau en dehors de ses limites...)

Admettons... C'est sans doute une meilleure pratique comme ça, en effet, mais en réalité c'est pas très respecté, comme convention. Notamment pas par la bibliothèque de base Java.

Citation:

---

Envoyé par _LittleFlea_

J'en déduis donc qu'il faut rajouter des instructions de test pour que l'exception ne se produise pas, on est d'accord ?

Par exemple, pour un Integer.parseInt(String s), il faut tester que s a bien un format numérique, on est toujours d'accord ?

---

Voilà c'est l'exemple typique.
Franchement, si la chaîne ne représente pas vraiment un entier, ce n'est pas la faute du programmeur, comment diable s'assurer que ça n'arrive pas ? Vérifier d'abord c'est quand même bien ridicule.

D'ailleurs les Format sont plus logiques : leur ParseException en cas d'erreur n'est pas une RuntimeException, et doit être traitée. Mais il est plus rapide et plus intuitif d'utiliser directement parseInt().

Citation:

---

Envoyé par _LittleFlea_

Juste pour avoir un exemple, comment testeriez-vous ça proprement ? (j'avais pensé à quelque chose genre s.matches("{-}?[0-9]+")...

---

Ce n'est pas mal, mais il faut aussi vérifier l'absence d'overflow. Et ça devient bien contraignant pour pas grand-chose.

Citation:

---

Envoyé par _LittleFlea_

Merci à vous de me dire si j'ai raison à propos de la gestion de l'exception :)

---

Tu essaies d'appliquer de bonnes pratiques. Mais ce n'est pas toujours simple à faire avec ce qu'on a.

Je te recommanderais plutôt de faire que toutes tes méthodes reposant sur Integer.parseInt() interceptent les NumberFormatException pour lancer une ParseException à la place. Ou quoi que ce soit d'autre, bref signaler à l'appelant qu'il peut y avoir une exception à gérer.

Citation:

---

Envoyé par _LittleFlea_

comment testeriez-vous ça proprement ?

---

Tout bêtement :

Code:

---

1 2 3 4 5 6 7

try { Integer.parseInt(s); } catch (NumberFormatException e) { // la chaîne s a un format incorrect // traitement d'erreur }

---

:aie:

Salut,


Les RuntimeExceptions sont bien moins contraignantes car elles ne nous obligent pas à les traiter. Elles sont généralement utilisé pour les erreurs de développement mais pas forcément. Cela peut dépendre au cas par cas...

Dans certains cas elles sont bien plus approprié que les checked-exception bien trop "lourde"...

Citation:

---

Envoyé par thelvin

D'ailleurs les Format sont plus logiques : leur ParseException en cas d'erreur n'est pas une RuntimeException, et doit être traitée. Mais il est plus rapide et plus intuitif d'utiliser directement parseInt().

---

Les Format et parseInt() ne font pas exactement la même chose. parseInt() utilise un format unique sans notion d'internationalisation ou de formatage complexe.


Toutefois parseInt() est un excellent choix quand au traitement des exceptions. On distingue deux cas différents :

• La donnée à parser provient (directement ou non) d'une saisie utilisateur.
• La donnée à parser vient d'une source sûr, et ne devrait jamais être incorrect.

Dans le premier cas, il est préférable de gérer l'exception afin de signaler le problème à l'utilisateur, et lui proposer de la ressaisir.

Dans le second cas il est par contre préférable de ne pas gérer l'exception. L'erreur ne devrait jamais se produire, donc pourquoi s'embêter avec un traitement qui alourdira le code et qui risquerait d'engendrer des comportements imprévu. Si malgré tout la donnée était incorrect, on aurait une exception qui ferait planter le programme...

:arrow: Le fait de faire planter le programme au plus tôt a beaucoup d'avantage. Cela permet en particulier de simplifier la rechercher des erreurs.
Après il faut voir si cela est acceptable ou pas. Mais dans bien des cas il est préférable de planter l'application plutôt que de la laisser continuer dans un état incohérent !!!


Après on garde la possibilité de présenter proprement ces erreurs via un UncaughtExceptionHandle...

a++