Newsgroup: it.comp.java
Titolo: Eccezioni

Avevo il problema di dover analizzare una stringa di massimo 15
numeri, un IP per capirci, costituto da interi e da tre punti.
Ho scelto quindi di raccogliere l'IP dentro una stringa.
Il problema era perň che l'IP poteva essere "sporcato" da altri
caratteri attaccati, ad esempio in questo modo: 
212.216.32.64</
Ovviamente dovevo ripulire l'IP dagli ultimi due caratteri e mi č
venuto in mente di utilizzare il metodo parseInt sull'ultimo carattere
della stringa, cosě se avessi trovato subito l'ultimo numero dell'IP
senza nessuna sporcizia attaccata non avrei avuto problemi, in caso
contrario avrei ottenuto un'eccezione del tipo NumberFormatException,
perchč avrei tentato di convertire in numero un carattere tipo "<".
La cosa mi ha sfiziato molto, poter usare in modo costruttivo
un'eccezione, cioč poter sfruttare un errore.
Bhe, contento del lavoro che ho fatto vorrei sapere perň se c'č un
altro modo per poter pulire una stringa come quella che ho scritto
senza utilizzare il metodo che ho descritto...anche se devo dire che č
ingegnoso...:))
***ICARUS DREAM***
I want to know God's thougths...
...the rest are details.
(Rimuovi una "e" dall'indirizzo)

 212.216.32.64</
Di preciso non so quanto 'pesi' la chiamata alla funzione parseInt, specie
considerando che probabilmente ti lancerà una eccezione, con conseguente
lavoro aggiuntivo ecc ecc. Io ti consiglierei di fare qualcosa del genere:
int l = myString.length() - 1;
while (!(Character.isDigit(myString.charAt(l))))
    l--;
myString = myString.substring(0,l + 1);
Magari mi piacerebbe sapere (ad esempio da Cristiano, o da Ugo, senza
nulla togliere agli altri) quanto pesa una chiamata a funzione che possa
lanciare o trappare una eccezione (se non è una richiesta 'fuori dal
mondo').
Ciao,
 Stefano
----------
"X WindowSSS, teSSSoro mio... lo odieremo per SSSempre"
Bill Gollum
----------


Il costrutto while(!( mi risulta assolutamente incomprensibile.
Capisco che č una contrattura di una forma piů estesa ma....vorrei
sapere qual'č la forma piů estesa.
Scusa ma sono ancora "giovane" del Java, anche se mi lancio in
avventure abbastanza ostiche.
Per quanto iguarda isDigit e charAt non li conosco, ma non ti
scomodare perchč andrň a vedere la documentazione della sun.
Grazie del consiglio....se potessi chiarirmi quel costrutto....:)



Bhe, alla fine, spulciando l'help sul sito della sun ho imparato ad
usare i metodi charAt e isDigit che mi avevi consigliato e tutto si è
risolto. Sono riuscito a fare quello che volevo in maniera molto più
semplice di quella che avevo in mente.
Certo che per conoscere tutti i metodi di una classe occorre passare
settimane a farsi gli occhi a palla davanti ai docs della sun.
Bhe, grazie per la dritta...mi sa che ti sfrutterò ancora in futuro ;)
A presto.


 Il costrutto while(!( mi risulta assolutamente incomprensibile.
while ! (not) è un carattere,
ovvero
while non è un carattere.
Se ti fa più comodo, immagina che esista (o di voler creare) l'opposto
del metodo isDigit, e che si chiami isNotDigit, che verifichi cioè se un
carattere NON è un digit. Cioè che ritorni true se NON lo è e false se
lo è, l'esatto opposto di isDigit(). Invece che scrivere un metodo del
genere, peraltro fattibile, basta invertire il risultato del metodo già
presente, isDigit(), con un operatore che ti dia true se gli passi false
e false se gli passi true. Questo operatore ovviamente esiste e si
chiama not, ma, ereditando java la sintassi qualche volta criptica del
c++ (che a sua volta la eredita dal c), si scrive !.
Quindi quando trovi !(condizione) in un while, if o dovunque, vuol dire
che la condizione sarà vera quando è falsa e viceversa.
Spero di non averti complicato la vita. Per esercizio, prova a creare
una nuova classe NewCharacter ereditando da Character e creando un nuovo
metodo isNotDigit() in modo da poter creare un ciclo while in cui non
appaia il famigerato operatore !, e, se vuoi, posta sul ng il codice
necessario.
Ciao
--
Ugo
__________________________________________________________________________
"La perfezione si ottiene non quando non c'è nient'altro da aggiungere,
 bensì quando non c'è più niente da togliere." Antoine de Saint-Exupéry
__________________________________________________________________________
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Enterprise Java Consulting
@mail: Ugo.L...@Flashnet.it
Home Page: 
http://www.ugolandini.net
Mentoring: 
http://www.projectoo.com
Work Phone: 02/61860647-6-4 06/58332267
Cell Phone: 0347/6310749 - 0347/4783580
Fax Phone: 02/700 413 187
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

 mondo').
Hai fatto qualche test? Così ad occhio direi che dipende dall'implementazione
del codice in particolare e sicuramente anche dalla particolare
implementazione della jvm, visto che comunque la gestione delle eccezioni fa
parte del nucleo "duro" di Java. Comunque sarebbe interessante fare dei test:
basta una piccola classe foo{} con uno stupido metodo in doppia versione, una
che solleva un'eccezione ed un'altra identica che non lo fa. Poi far girare un
po' di test con implementazioni diverse del metodo (per evitare magari di
incappare in particolari ottimizzazioni della jvm) con diverse jvm e vedere
currenTimeMillis() che ci dice.


necessario.
Assolutamente chiaro.
Grazie.


l'ordine di ricerca degli handler :)
Ops, volevo dire "invocazione", non ricerca. 
-- 
God is Real, unless declared Integer.
ObjectZone - 
http://space.tin.it/computer/csadun/

mondo').
Se nessuna eccezione viene sollevata, il costo di un blocco try..catch e' solo 
in spazio - per la tabella di gestione e le entries relative agli exception 
handler.
Se invece un'eccezione viene sollevata (cioe' da qualche parte e' eseguita una 
"throw"), a parte ovviamente il costo dell'handler stesso (cioe', le istruzioni 
che rispondono ;-), l'overhead e' dovuto al lookup nella tabella e, quando 
l'handler viene trovato, ad un paio di push aggiuntivi sullo stack (di this e 
del reference all'eccezione). 
L'algoritmo di lookup ha una semantica precisa (in termini piu' umani, precisa 
l'ordine di ricerca degli handler :) e la tabella e' "semplice", cioe' un array 
di strutture (attributi, in gergo, dato che sono memorizzati nel constant pool 
della classe) che contengono inizio/fine del codice "controllato" (in termini 
di program counter), inizio dell'handler, e classe dell'eccezione.
Queste due cose (l'ordinamento, e il fatto che la tabella e' semplicemente un 
array) implicano che il lookup non puo' essere troppo sofisticato: si deve 
sostanzialmente fare una ricerca sequenziale sugli handler verificando quale 
sia quello giusto da chiamare. 
Il trucco e' che e' il compilatore a decidere l'ordinamento nella tabella, e 
quindi - complice il fatto che le eccezioni sono strutturate - puo' garantire 
che i *primi* handler controllati siano quelli che, nel caso "gestiscano" 
l'area di codice che ha generato la throw, siano proprio quelli "giusti" da 
chiamare. Quindi ci si puo' aspettare che il costo cresca solo linearmente 
coll'aumentare delle eccezioni gestite localmente. 
Ovviamente potrebbe esserci un compilatore particolarmente imbecille :) che 
compila le entries fuori ordine - nel qual caso il costo sarebbe quello, 
pesante, di una ricerca sequenziale.
L'algoritmo di lookup, ovviamente, e' parte della JVM e quindi scritto in 
codice nativo.
Cose come handler innestati e eccezioni non gestite localmente sono risolte in 
compilazione, quindi non danno problemi. Oh, quando un'eccezione non e' gestita 
localmente, c'e' anche il costo di deallocazione dello stack frame relativo - 
ma questa non e' una novita'. ;-)


 [SNIP un sacco di documentazione tecnica e molto interessante]
Grazie, è davvero molto interessante. Hai preso queste informazioni dal libro della
Sun sulla Java Virtual Machine? Mi sa che me lo leggerò quando avrò un attimo di
tempo... ossia quando avrò finito di rileggermi Java Servlet Programming e quando
mi sarò letto Java Threads e Java I/O che finalmente mi sono arrivati...




Mi interessa trovare documentazione su i compilatori java (anche diversi da javac),
e ho l'impressione che tu sia la persona giusta a cui chiedere;
Sapresti darmi dei link a dei documenti che non siano solamente introduttivi?
grazie
Ettore

libro della Sun sulla Java Virtual Machine? 
Quello, e' un disassembler fatto a mano per vedere il bytecode.. ma era
tempo fa. Oggi consiglierei l'NMI CodeViewer. :) 


solamente introduttivi? 
Be', i document chiave sono la JVM Spec e la JL Spec, con le note per i
costruttori di compilatori. E' forse utile cercare di ottenere una
licenza completa di sorgenti per il compilatore da Sun. Inoltre, se non
ricordo male ci sono altre pubblicazioni Sun in proposito, e qualcosa
dovresti trovare anche ad IBM. Purtroppo non saprei essere piu' preciso. 
