salut,
j'aimerais tester si une chaine de caracteres est un nombre, j'ai cherché dans l'API String y a apparemment pas de méthode pour ça ...
 
une idée ?
 
Merci.

Ben ca dépend du nombre que tu cherches...
 
mais le principe est le même :  
 
si c un entier que tu testes en saisie, fait un  

merci

Ya plus propre a mon gout Character.IsDigit(...) qui renvoie vrai ou faux... :$

qui test un caractere, comme le laisse comprendre le nom de la classe, et pas une chaine entiere

 
Je ne suis pas un expert en Java, mais je trouve cette structure orripilante ... Un try catch est une structure de gestion d'erreurs, elle est la pour reperer si qqch merde dans le programme et signaler l'erreur, c'est en principe pas un If/else deguisé pour l'occasion..

oui et donc si on récupère une string composé de lettre au lieu de chiffres, c pas suffisament une erreur pour toi ?

J'aurais dis pareil que Jubijub.

 
Sisi mais c'est plutot le "catch + On lui fait continuer le programme d'une autre maniere" qui me derrange... Quand j'avais appris le Java on m'avait dit qu'au lieu de faire un truc comme ca, il fallais verifier si la variable etait composée de nombres et faire un if/else. Parceque c'etais plus "dans l'optique de ce que doit faire le catch". C'est pour ça que j'ai tilté ... Ce genre d'ecriture m'a vallu un nombre non negligeable de tapes dans la nuque, qu'elle n'est pas prete d'oublier

ben c le but d'un catch selon moi ...
 
au niveau métier, tu veux un nombre....le fait que ca puisse etre une chaine de caractère pas uniquement numérique est une possibilité relativement probable. C'est une erreur qui peut nuir à l'intégriter de ton modèle : c donc normal que ca déclenche une erreur
 
Le if/else est pas terrible car :  
- le parseur utilise le méchanisme de l'exception ...avec un if/else, faudrait t'amuser à boucler sur le tableau de char composant la String, bref, un peu chiant
- si tu détecte l'erreur avec ton if/else, tu fais quoi ? avec une exception, tu peux la catcher, ou la remonter dans les couches, pour déclencher un popup d'erreur par exemple
 
 
mais sinon je suis d'accord, par un un controle pour voir si un truc est nul ca doit etre fait par un if/else, ce serait dégueux de catcher systématiquement la NullPointerException ...encore qu'on doit pouvoir trouver des cas où ca se justifierait...

là il n'a pas le choix, c'est pas lui qui a écrit parseInt(), et il n'a pas de raison d'écrire un parser. Il s'adapte donc.

de plus qu'aurait-il fallu ? faire une méthode qui te dit si oui ou non c'est un chiffre (=> nécessite un parsing) puis, si c'est bien un chiffre, il faut refaire un parsing (=> 2e parsing)
 
là tu peux faire les 2 en un, au prix d'une levée d'exception potentielle c'est vrai.
 
Remarque : dans la quasi totalité des cas, quand j'utilise cette méthode, le cas où ce n'est pas un nombre est réellement une erreur, et je throws une exception dans le catch.

Ok , faudra que j'aille rechercher mon prof de l'epoque pour lui rendre ses claques

non mais dans l'absolu, moi je suis d'accord avec esox_ch; faut juste voir comment tu peux le faire concretement en java, et quelle utilisation tu as du truc. (ça me rappelle un certain débat sur le FileNotFoundException ).
 
le tout est de savoir, comme ça a été déjà dit je crois, si le fait de ne pas avoir un nombre est une erreur ou pas.

Pour moi tout ce qui est controlable au prealable avec un if, ne peut pas etre considéré comme une erreur ... maintenant ... comme le dit benou ... c'est parfois tres pratique de pouvoir declancher une erreur ... perso je trouve qu'il s'aggit de faire un compromi entre la semantique du code et la simplicité de programation ..

j'ai pas tout compris à vos argumentaires là.
 
Mais j'aimerai simplement rappeller sue la fonction int parseInt(String) n'a aucun moyen de renvoyer une valeur spéciale pour signaler une entrée erronnée (0, -1, etc. sont des valeurs normales) , donc elle ne peut le faire qu'au travers d'une exception. Duc la question de situation exceptionnelle ou pas, ne se pose pas : on a pas le choix.
 
la version Integer parseInt(String) par contre, peut renvoyer null en cas d'erreur, c'est une valeur spéciale.

je parlais "dans l'absolu", sémantiquement, et sans tenir compte des implémentations existant ou pas dans la jdk actuelle.

Oui en l'occurence c'est vrai. D'ailleurs j'ai un peu melanger Java et PHP sur ce coup, etant donné qu'en php la fonction is_numeric() retourne si oui ou non l'argument est un nombre (int, double,...) alors que si je me rappelle bien en Java ce genre de truc controle seulement en tant que quoi la variable a été declarée et non pas ce qu'elle contient "reelement" (par exemple un nombre contenu dans une variable string)

Bonjour,
 
Pour ceux qui sont débutants comme moi et qui ne connaissent pas encore le try/catch ou les expressions régulières ;-)  
 
voici un petit exemple basique de test d'une zone saisie au clavier (la décimale est définie par un point dans ce cas sinon met une virgule ;-)
 
String saisie  = zone saisie au clavier (ou à tester :-) ...                                
char [] tab = saisie.toCharArray();
boolean estUnNombre=true;
for (int i=0;i<tab.length;i++ ){
    if (Character.isDigit(tab[i])) {  } // ne rien faire ;-)
    else { if (tab[i]!='.' && tab[i]!='-') estUnNombre=false; } // remplace le point '.' par virgule ',' ou ajoute un caractère comme '+' ;-)  
}
if (estUnNombre) {  } // ton traitement ici :-)
else { System.out.println("La valeur saisie n'est pas un nombre" ); }
 
bon courage aux newbie comme moi ;-)

Usine à gaz potentiellement buggogène => go pour le Integer.parseInt() ou Float.parseFloat() + gestion exception
D'ailleurs j'ai déjà trouvé un cas foireux : si tu lui passe "65.-02", il va répondre OK alors que c'est pas un nombre. Idem si tu saisis "6.5.25"

Le seul bémol pour l'utilisation des exceptions, c'est que si c'est voué à être appelé à grande échelle dans une boucle, ça va pourrir les perfs. La gestion d'exception est très très lente.

Sinon, y'a l'option expression régulière mais si tu connais pas assez pour l'écrire toi même, c'est pas forcément évident de tester pour vérifier que tous les cas fonctionnent !
 
Mais en mode expression régulière, ça donnerait un truc comme ça :