Version imprimable
zut, moi qui venais annoncer fièrement que je m'en étais sorti grâce aux expressions régulières :aie:
je suppose que ta solution à toi est moins gourmande hein?
EDIT : puisqu'on parle de gourmandise, en général je met des catch(Exception e) sans me soucier du type d'exception. Est ce que c'est vraiment mal? ou est ce que la précision permet juste de traiter chaque exception d'une façon différente?
L'expression régulière sera construite à chaque test, tandis que l'exception ne le sera que dans le cas où le test échoue. Après rien ne dit que la différence de perfs sera notable.Citation:
Envoyé par boitaRytm
L'autre avantage de la solution "parseInt" est que l'algorithme de vérification/parsing est déjà implémenté ;).
Il est préférable d'être précis dans les clauses catch ;).Citation:
Envoyé par boitaRytm
tu m'aurais dis ça avant que je l'implémente ça aurait un argument choc :lol:Citation:
L'autre avantage de la solution "parseInt" est que l'algorithme de vérification/parsing est déjà implémenté
de toutes les façons l'inconvénient avec parseInt c'est que c'est limité au niveau de la taille. même avec parseLong mes chaines hexa sont trop longues. j'ai donc gardé ma solution avec l'expression régulière. tant pis !
préférable oui, mais pourquoi? pour les performances ou pour un code plus lisible et plus précis ?Citation:
Il est préférable d'être précis dans les clauses catch
Il n'y a aucune différence en terme de performance, ce n'est qu'une question de design de l'application notamment, comme tu dis, pour un code plus lisible et plus précis.Citation:
Envoyé par boitaRytm
Après ça ne veut pas dire que tu ne peux pas utiliser directement le type Exception ;).
d'accord. je veux bien essayer de fournir un code lisible et précis, mais bon c'est moins important que si c'était un problème de performance.
merci beaucoup pour tes réponse. et navré d'avoir posé plusieurs questions qui ne soient pas en relation directe avec le sujet. simplement les problèmes c'est comme les trains, ça en cache souvent un autre :roll:
C'est aussi un problème de traitement des erreurs inattendues... Il est possible d'obtenir lors de l'exécution du programme des RuntimeException, dont le traitement n'est pas prévu dans le fonctionnement "normal" de l'application, or un catch (Exception e) dans lequel tu n'as prévu que le traitement des erreurs "normales" va masquer ces erreurs inattendues.Citation:
Envoyé par boitaRytm
Exemple. Tu effectues un traitement sur un tableau susceptible de lever l'exception MonException, tu effectues un catch (Exception e) en pensant que "normalement" seule l'exception MonException pourra être interceptée, et manque de bol lors de l'exécution tu obtiens une IndexOutOfBoundsException : elle sera alors traitée comme une MonException et tu ne te rendras pas même compte de l'erreur dans ton algorithme, tandis qu'avec un catch (MonException e) l'exception inattendue, non interceptée, aurait interrompu le programme et t'aurait permis de remarquer le problème ;)
Il vaut donc mieux traiter les exceptions en étant le plus précis possible sur la nature des exceptions interceptées, de façon à ne pas ratisser trop large sans s'en rendre compte.
bonjour,
effectivement de ce point de vue là ça peut jouer de mauvais tours :aie: