[java] Erorre banale..

[anx721]

Originariamente inviato da ChReAn
Puoi usare Int al posto di int.
Alcuni tipi di dati di base hanno dei wrapper (Float per i float, Double per i double, ecc...) che consentono di agevolare le conversioni.
Ad esempio tu potresti scrivere

Integer Start = new Integer(args[0]);

Questi tipi di dati infatti possiedono dei costruttori che si occupano di castare in automatico il parametro passato.
Per ottenere poi il valore della variabile, bastera' richiamare Start.intValue().

Oppure puoi piu semplicemente utilizzare direttamente il metodo statico parseInt(String num) della classe Intger che trasforma una stringa num nel corrispondente numero intero che rappresenta:

int Cont=0;
int Start=Integer.parseInt(args[0]);
Start++;
int End=Integer.parseInt(args[1]);


Ciao

[LeleFT]

Ricordati che, se vuoi convertire una stringa in un tipo di dato intero, (sia che tu voglia trasformandolo in un oggetto di tipo Integer, che in un int usando il metodo statico parseInt()) devi usare un blocco try...catch per catturare una possibile eccezione.

Sia il metodo parseInt() che il costruttore della classe Integer, infatti, possono generare un'eccezione di tipo NumberFormatException e se non racchiudi le istruzioni in un blocco try...catch il compilatore non compilerà mai.


Ciao.

[ChReAn]

Originariamente inviato da anx721
Questo vale in c, in java args[0] non è inizializzato con il nome del programma, quindi i parametri passati dalla linea di comando iniziano ad essere inseriti a partire dall'indice zero, ciao.

Allora mi scuso per l'imprecisione e mi cospargo il capo di cenere.

[alex86]

Originariamente inviato da LeleFT
Ricordati che, se vuoi convertire una stringa in un tipo di dato intero, (sia che tu voglia trasformandolo in un oggetto di tipo Integer, che in un int usando il metodo statico parseInt()) devi usare un blocco try...catch per catturare una possibile eccezione.

Sia il metodo parseInt() che il costruttore della classe Integer, infatti, possono generare un'eccezione di tipo NumberFormatException e se non racchiudi le istruzioni in un blocco try...catch il compilatore non compilerà mai.


Ciao.

illuminami :gren:

[Zero-2]

Sia il metodo parseInt() che il costruttore della classe Integer, infatti, possono generare un'eccezione di tipo NumberFormatException e se non racchiudi le istruzioni in un blocco try...catch il compilatore non compilerà mai.

Non è vero che non lo compilerà mai se non lo racchiudi in un try/catch . La NumberFormatException è una RuntimeException che non necessita obbligatoriamente di un try/catch.

[LeleFT]

Originariamente inviato da Zero-2
Non è vero che non lo compilerà mai se non lo racchiudi in un try/catch . La NumberFormatException è una RuntimeException che non necessita obbligatoriamente di un try/catch.

Hai ragione... non è obbligatorio ed il compilatore non fa storie (e questa E' UNA PECCA DEL COMPILATORE JAVA). Resta comunque il fatto che chiunque può commettere degli errori in fase di digitazione e non è bello vedersi terminare l'applicazione all'improvviso con un messaggio d'errore (il programmatore dovrebbe evitare al massimo queste situazioni).


Per alex86:

try {
   Integer Start = new Integer(args[0]); 
} catch (NumberFormatException nfe) {
   System.out.println("Non hai introdotto un numero.");
}

o meglio

Integer Start = null;
try {
   Start = new Integer(args[0]); 
} catch (NumberFormatException nfe) {
   System.out.println("Non hai introdotto un numero.");
}

Puoi anche non fare niente nel blocco catch, ma in questo caso, se l'utente introduce qualcosa che non è un numero, si vedrà terminare l'applicazione senza sapere perchè.

Ho messo la seconda alternativa perchè in questo modo è sufficiente racchiudere nel blocco try/catch soltanto l'operazione di conversione stringa->numero, senza avere problemi nell'uso della variabile Start al di fuori dello stesso blocco.


Ciao.

[Zero-2]

(e questa E' UNA PECCA DEL COMPILATORE JAVA)

Metti il caso di avere una JTextField nella quale devi inserire un valore numerico , il controllo lo fai quando immetti i caratteri tramite un KeyListener , bloccando l'inserimento di lettere e/o punti ....
Andando a convertire la stringa così ottenuta sei sicuro che non lancerà un NumberFormatException e quindi è inutile che il metodo sia contenuto in un try/catch.

[alex86]

Molto d quello ke dite è arabo...

Cm mai trovo problemi a capire bene come funziona java anke se conosco linguaggi come php e asp..non penso sia solo il fatto ke questi sono latoserver e la loro programmazione non è ad oggetti...

conoscete qualke buon manuale online?ho scaricato sia il mokabook ke il mattone ma a dir la verità...nn hanno ritegno dei nuovi di questo linguaggio cm me

[LeleFT]

Originariamente inviato da Zero-2
Metti il caso di avere una JTextField nella quale devi inserire un valore numerico , il controllo lo fai quando immetti i caratteri tramite un KeyListener , bloccando l'inserimento di lettere e/o punti ....
Andando a convertire la stringa così ottenuta sei sicuro che non lancerà un NumberFormatException e quindi è inutile che il metodo sia contenuto in un try/catch.

E metti il caso che il tuo KeyListener sia stato progettato bene... ma che ti sia sfuggita una cosina, anche piccola (non hai idea di quante volte capiti, spesso in progetti che coinvolgono una ventina di classi). Il tuo progetto andrà in errore e tu non capirai dove stai sbagliando (metti poi che la tua applicazione non venga avviata da riga di comando, non hai una finestra di shell dove vedere gli errori...).

Java è stato pensato per ridurre al minimo le possibilità di errore (anche perchè essendo multipiattaforma questi si moltiplicano) e anche i Runtime Exception sono errori (dovuti, magari alla semantica).

Questo intendo io con PECCA DEL COMPILATORE. La filosofia di Java è quella di COSTRINGERE il programmatore a prevedere gli errori, evitarli e gestirli. Così non si evitano, non si gestiscono e si permette il crash.

Non ti preoccupare... non sto polemizzando (anche i Sistemi Operativi come Unix, Linux e Windows FANNO FINTA che alcune situazioni non si verifichino... però l'esperienza ci insegna che così non è).

Per alex86: quello che ti serve non è un manuale di Java, ma un libro che insegni la programmazione Object Oriented. Per ora non ne conosco di fatti bene (quello che abbiamo usato noi all'università, secondo me, è PESSIMO e non te lo consiglio proprio).


Ciao.

[Zero-2]

X LeleFT

Sono d'accordo sul fatto che aiuti ,catturare le eccezioni, a capire dove si sbaglia , e so cosa questo significhi in un progetto molto vasto.
Però alcune è comodo non dover gestire forzatamente un'eccezione.
Non voglio nemmeno io far polemiche
:adhone:

X alex86 :
Se vuoi un buon libro su Java puoi usare Java 2 i fondamenti della McGrawHill