Dans le cas du parseInt ce n'est pas qu'une question de performance (on ne peut pas influencer ce que la routine fait en interne, donc discuter de ces bidouilles pour rendre la solution moins mauvaise n'est pas vraiment utile et ne signifie PAS savoir coder) c'est plutôt qu'il y a plusieurs cas:
* Soit le fait que ce soit effectivement un entier est obligatoire à la suite du programme (typiquement dans un compilo: integer token expected here ou sinon je plante et je quitte), dans ce cas lancer une exception est justifié,
* Soit on aimerait bien que ce soit un entier, mais ce n'est pas fatal (typiquement on va mettre un message en rouge devant le champ), et à ce moment-là c'est une mauvaise solution. Certains la résoudront avec une suite de try catch mais ça ne cause que des problèmes et c'est moche. Le problème vient du fait que si on fait un try catch sur toute la validation du formulaire, il n'y a pas moyen d'indiquer spécifiquement ce qui s'est mal passé. C'est pour ça que le modèle est mauvais.
En attendant la solution la moins pire est d'utiliser une regexp (ou au pire de wrapper les try catch dans des validateurs mais
), mais il y a de quoi se taper la tête contre les murs.