Newsgroup: it.comp.java
Titolo: Gestione eccezioni

Salve a tutti. E' da un po' che programmo in java ma mi sono sempre
posto il seguente problema sulla natura delle eccezioni.
In linguaggi come il C un errore viene segnalato tramite il valore di
ritorno di un metodo oppure settando il valore di alcune variabili
globali che poi lo sviluppatore può controllare. Queste variabili sono
definite come interi e si posso fare dei confronti con costanti
definite negli header per capire che tipo di errore è accaduto.
In Java ci sono le eccezioni con i loro vantaggi che noi tutti
sappiamo, basta cercare su google "gestione delle eccezioni in java".
Prendiamo la classe IOException. IOException può essere lanciata se ci
sono problemi di input o output da/verso un dispositivo. Quello che mi
chiedo, come posso capire esattamente il problema che ha generato la
IOException? Qualcuno direbbe scrivi e.getMessage() e hai risolto. Si,
ho risolto se il mio intento è quello di visualizzarlo a qualcuno, ma
se invece è il mio programma a voler sapere che cosa è successo?
Prendiamo la classe PipedInputStream, il cui metodo read() lancia una
IOException in questi casi: se non è connesso a nessun
PipedOutputStream, se è chiuso o per un altro errore di I/O.
Nel mio programma ci saranno le linee di codice try{ ... read(); ...}
catch(IOException e){}. Se nel blocco del catch volessi sapere se la
IOException è stata lanciata per stream chiuso, per stream non
collegato o per un altro tipo di errore, come dovrei fare?
Grazie mille,
Davide

 mio programma a voler sapere che cosa è successo?
e.printStackTrace()
Eclipse (penso anche NetBeans) ha anche il supporto per il posizionamento
sulla riga di codice cliccata in console.
Più comodo di così!
Dopodiché, debug.
Farlo con il debugger di una IDE è anche più comodo.
Ciao
gl

 gl
Credo che intendesse un'altra cosa. Lui vuole gestire da
programma le diverse casistiche dell'errore, che sono
perň accomunate da un solo tipo di Exception.
A quanto pare non ci sono altre informazioni oltre
al messaggio e allo stack trace. Quindi non credo
si possano distinguere i "sottocasi" in modo semplice.

 si possano distinguere i "sottocasi" in modo semplice.
La butto li: non si potrebbe utilizzare la stringa ritornata da 
e.getMessage()? Cioč, poichč mi p sembrato che il piů delle volte questa 
stringa e' "personalizzata" per ogni tipo di eccezione, se la stringa 
contiene ad esempio "connection closed" allora l'IO č stato chiuso, e cosě 
via... 

 collegato o per un altro tipo di errore, come dovrei fare?
Puoi crearti tu un tuo set di eccezioni da usare nella tua applicazione.

 via...
Potrei recuperare e.getMessage() e poi fare un confronto con le varie
possibili stringhe,
ma chi mi dice che il messaggio sarà sempre quello? Magari nella
prossima release di java
quel particolare messaggio contiene uno spazio in più e così il
controllo non funzionerà.
Possibile che i realizzatori non abbiano pensato mai a una cosa del
genere?

genere?
Puoi farci un esempio di cosa faresti se tu avessi le informazioni
che cerchi, ovvero se tu potessi distinguere le diverse ragioni
che hanno portato all'exception ? 

 genere?
Mah, non credo che i messaggi di errore rischino di esser cambiati 
spesso...ovviamente non si può fare affidamento su un "pensiero".... io 
avevo avuto lo stesso problema, che ho risolto con miniblocchi try-catch, 
ovvero uno all'apertura di una connessione (nel mio caso un db in remoto), 
un per la connessione al db, uno per la chiusura della connessione....in 
questo modo catturavo l'eccezione spendone "la causa" ma non so quanto sia 
valida come soluzione.... 


Ad esempio, sempre per il caso della PipedInputStream, se sapessi
cosa
ha causato la IOException scriverei la causa in output in italiano:
If(io_exception == PIPE_NOT_CONNECTED)
   System.out.println("Pipe non connessa");
if(io_exception == PIPE_CLOSED)
   System.out.println("La pipe è chiusa");
ecc...
Grazie, Davide

 Puoi crearti tu un tuo set di eccezioni da usare nella tua applicazione.
Lui sta parlando di eccezioni generate dalle classi standard della JDK 
(per es. InputStrem) ..come fai a sovrascriverle??

 (per es. InputStrem) ..come fai a sovrascriverle??
no ovviamente non puoi :)
perň secondo me il punto rimane concettualmente lo stesso, e cioč:
č l'autore di una "scatola nera" a decidere che tipo di eccezioni questa 
scatola nera puň lanciare.
Se l'autore della scatola č Davide, tanto meglio, si costruisce lui le 
eccezioni di cui ha bisogno e sta a posto.
Se č stato qualcun altro, e non potendo mettere le mani nella scatola nera, 
bisogna lavorare con quello che si ha.
E probabilmente nella maggioranza dei casi non si ha bisogno di sapere se la 
PIPE č chiusa o mezzachiusa o otturata :)))
Insomma, a chi usa la scatola nera chiamata "sistema di I/O" importa che c'č 
stato un'errore nell'IO, col dettaglio cosa se ne fa? solo per visualizzare 
un msg di errore specifico? e a che pro? visto che comunque lui non č in 
grado di mettere le mani e intervenire dentro la scatola nera per magari 
recuperare l'errore, visto che la scatola non l'ha costruita lui :)
In ogni caso poi, la IOException si specializza in:
ChangedCharSetException, CharacterCodingException, CharConversionException, 
ClosedChannelException, EOFException, FileLockInterruptionException, 
FileNotFoundException, IIOException, InterruptedIOException, 
MalformedURLException, ObjectStreamException, ProtocolException, 
RemoteException, SocketException, SSLException, SyncFailedException, 
UnknownHostException, UnknownServiceException, UnsupportedEncodingException, 
UTFDataFormatException, ZipException

 recuperare l'errore, visto che la scatola non l'ha costruita lui :)
Se non sbaglio, si può risalire alla causa dell'errore utilizzando a
cascata il metodo getCause().
Bye
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

secondo me se vuole valotare e fare una specie di statisctiva degli
errori che possono intercorrere nel suo programma anzichè raccogliere
direttamente un IOException gli conviene prima intercettare tutte le
eccezioni che specializzano IOException e poi raccogliere la
IOexception (può sempre esserci il caso in cui si usi una libreira non
standard che ha una eccezione che specilaizza la IOException...)
si non sarà il massimo dell'eleganza e soprattutto della comodità ma
in questo modo ha quasi la certezza di scoprire con precision l'errore
che si è verificato
Ciao
Marco