Newsgroup: it.comp.java
Titolo: evitare di lanciare una NumberFormatException

Ciao a tutti,
nella traduzione di una stringa in un intero la cosa più comune che ho visto
fare (e quella che ho fatto fin'ora) è:
try {
        int n = Intger.parseInt(<stringa>);
}
catch(NumberFormatException nfe) {
        <gestione dell'errore>
}
D'altra parte NumberFormatException non è una CheckedException e questo
sistema non mi sembra molto corretto.
Come controllare che la stringa sia un intero valido prima di eseguire
parseInt()? (Con le librerie, E' chiaro che ci vorrebbe un attimo a
scrivere un metodo che lo faccia).
Ho frugato e non ho trovato molto. L'unica cosa che mi è venuta in mente è
questa:
//assumo di essere in base 10 quindi 2^31-1 si esprime con 10 cifre
if(<stringa>.length()>10) 
 <errore>
NumberFormat nf = new DecimalFormat(<pattern opportuno>);
Number num = nf.parse(<stringa>,new ParsePosition());
if(num == null || num.longValue()>Integer.MAX_VALUE)
  <errore>
int numero = num.intValue();
Mi sembra a dir poco laborioso :)
C'é un modo più semplice e/o elegante? Esiste un pattern che faccia
funzionare questo codice?
Grazie!
-- 
chi sono e soprattutto chi non sono:
http://www.ilnomedeldominio.it
un piccolo programma per studenti universitari:
http://inutility.ilnomedeldominio.it

 fare (e quella che ho fatto fin'ora) è:
 > [...]
Ciao matish
secondo me forse i metodi parseXXX dei wrapper numerici dentro il 
package java.lang (come appunto Integer) sono stati creati più che altro 
per utilizzo "interno", o comunque all'interno di casi in cui è raro 
aspettarsi un'eccezione e magari si vuole incrementare al massimo le 
prestazioni (penso ad esempio ad un deserializzatore di oggetti da file, 
oppure un semplice lettore di formati binari).
Per le situazioni da "errore dietro l'angolo" come ad esempio l'input da 
tastiera si dovrebbe invece probabilmente usare le classi del package 
java.text (come DecimalFormat) che invece sono pensate appunto con 
l'idea del parsing in mente e lanciano infatti la ParseException che è 
una bella Checked Exception da gestire obbligatoriamente. Tra l'altro 
infatti già nel momento in cui non devi ottenere più un intero ma un 
double l'utilizzo di un DecimalFormat ti semplifica la vita non poco :)
Ciao :)
pole

 sistema non mi sembra molto corretto.
perchè non ti sembra corretto?
a me sembra codice molto pulito
stai tentando di convertire una stringa in intero
e se qualcosa non funziona ottieni un exception
che è un metodo molto comodo per segnalare un problema
ciao)o
Andrea
http://jame.sf.net

 perchè non ti sembra corretto?
Perché secondo me (e secondo altri più autorevoli :) le unchecked exceptions
vengono lanciate in casi anomali che non dovrebbero verificarsi. Quindi non
andrebbero gestite. Gli imprevisti si "prevedono" con le checked
exceptions.
E' un po' come fare questo:
try {
  for(int i =0; ; i++)
   array[i];
}
catch (ArrayIndexOutOfBoundsException ai) {
 //esco dal ciclo
}
per uscire da un ciclo. L'esempio è volutamente esagerato ma rende l'idea :)


 exceptions.
ok, ora ho capito
in sostanza secondo te sarebbe piů corretto
se NumberFormatException invece che estendere
RuntimeException estendesse semplicemente Exception?
ciao)o
Andrea
http://jame.sf.net

 
E' corretto.
-- 
You dont know what to do when you dont know what you're doing.
http://space.tin.it/computer/csadun

 E' corretto. 
Ti ringrazio del parere, mi spiegheresti anche perché per favore?
:)
Grazie
Matteo


 RuntimeException estendesse semplicemente Exception?
Sarebbe più corretto se il valore venisse controllato prima.
Tipo
if(<stringa> è un numero)
  int numero = Integer.parseInt(<stringa>);
else 
  <gestione dell'errore>
ed in caso di imprevisto (questo non lo è visto che so che potrebbe non
essere un numero, ad es. input da tastiera) il metodo fa bene a lanciare
una uncheked exception che fa bene a terminare il mio programma.
Non so se ora mi sono spiegato :) 
Ciao


 Matteo
Certo. :) La condizione e' un'eccezione rispetto a quanto atteso; e' piu' 
chiaro di un if; l'overhead necessario per installare un exception handler 
al posto di un if successivo e' insignificante nel contesto.


 al posto di un if successivo e' insignificante nel contesto.
Ok, però il fatto una exception sia unchecked dovrebbe implicitamente 
significare che non ci sia da attendersi un'eccezione in tal contesto, 
oppure che se proprio dovesse verificarsi sarebbe un problema 
attribuibile al non corretto utilizzo dell'API. Come una 
NullPointerException, basta verificare che obj != null e siamo sicuri 
che non si verificherà mai.
Il discorso che ho fatto nel mio post non vi convince?
Ciao :)
pole

 wrote in
news:c2pkr5$cr4$
1...@lacerta.tiscalinet.it
: 

Non avevo letto (pardon :) ma si', fila. 
Tuttavia, il mondo e' pieno di gente che usa parseInt() - che e' anche 
piu' immediato da usare di DecimalFormat e/o semplicemente piu' vecchio e 
quindi piu' noto - e nel caso, il significato "formato del numero non 
corretto" e' incapsulato esattamente da quell'eccezione, cosi' tanto vale 
usarla - o almeno, non e' un problema a cui dedicare piu' di due 
picosecondi di attenzione. Riguarda piu' la forma che lo spirito dell'OO, 
imvho. :)


 imvho. :)
Perfetto. Se chi ha aperto il thread è d'accordo direi che siamo giunti 
a una conclusione :)
pole