Discussion :

[_LittleFlea_]

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+

[thelvin]

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.

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().

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.

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.

[adiGuba]

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"...

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...

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++

[Astartee]

comment testeriez-vous ça proprement ?

Tout bêtement :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
}