Newsgroup: it.comp.java
Titolo: Re: java ed Eccezioni

 
Questo è chiaro ;-) Intendevo dire che non puoi fare:
try
{
   istruzione1; //genera un'eccezione
   istruzione2;
   ...;
}
catch (MiaEccezione me)
{
   ...;
   riprendi da istruzione2;
}
operazione consentita dal costrutto On Error Resume Next di VB.
Ciao :)
-- 
_ _ _  _  /_
  _ /_//_///_' ___
   / and yet it does move...

 Ciao :)
Questo l'avevo capito :)  era una "piccola" provocazione per porre 
l'accento sul fatto che uno deve essere consapevole della gestione degli 
errori.
Ciao.

 Ciao :)
guarda pole che quello che hai hai scritto, che per fortuna non si può
fare, nasconde un potenziale loop
infatti hai messo anche istruzione2 nel blocco try/catch, e se anche
istruzione2 generasse l'eccezione MiaEccezione non ne usciresti
la soluzione è semplicemente:
try{
   istruzione1; //genera un'eccezione
}catch (MiaEccezione me){
   ....
}
try{
   istruzione2; 
}catch (MiaEccezione me2){
   ....
}
oppure se istruzione2 non espone MiaEccezione:
try{
   istruzione1; //genera un'eccezione
}catch (MiaEccezione me){
   ....
}
istruzione2; 
Comunque io sono per NON scrivere del codice gestendo le eccezioni
come sopra.
Anche io all'inizio trovavo scomodi i try/catch ma poi ne ho capito la
filosofia e quindi come usarli e sono formidabili.
Innanzitutto sappi che puoi crerarti delle tue eccezioni personali,
dove inserirvi anche tuoi metodi perticolari che possono essere
richiamati durante la gestione del catch.
Ti consiglio di cercare di NON intercettare mai le eccezioni con dei
try, ma implementare  "throws" nei metodi che racchiudono istruzioni
che espongono eccezioni.
Infatti la filosofia da usare non è quella di incasinare il codice con
le try/catch (si perde anche visibilità), ma lasciare che le varie
eccezioni si attivino, facendo si che java risalga la gerarchia dei
metodi nidificati (stack), in modo che sia (per quanto possibile)
sempre il PRIMO medoto che ha generato il processo a gestire le
"catch", e non tutti gli altri.
In questa maniera il tuo codice sarà moplto leggibile ed affidabile,
perchè a gestisce le eccezioni saranno SOLO i metodi che hanno datao
inizio ad un processo, anche se questo può arrivare a generare stack
(nidificazione di classi e metodi) molto profondi.
Se ci pensi bene è giusto così, perchè sono chi ha dato inizio ad un
processo sa esattamente cosa fare in caso di eccezioni; mentre i
singoli metodi di servizio che possono essere richiamati da pià
processi, potrebbero gestire le eccezioni in maniera non conforme al
processo nel quale vengono richiamati.
Ad esempio un metodo di servizio che calcola un saldo, potrebbe essere
richiamato da un processo di inserimento movimenti oppure da un
processo di cancellazione movimento, e l'eventuale eccezione che si
può generare durante il ricalcolo del saldo è bene che vada gestista
diversamente in base al fatto che sia stata incontrata durante un
inserimento piuttosto che durante una cancellazione.
Guarda che paradossalmente è molto, ma molto più semplice di quanto tu
possa immaginare.
eseguiAggiorna () {
 try { // qui inizia un processo (es.l'utente ha fatto click di
aggiorna)
    metodo1()
    metodo2()
 }catch(eccezione1 e1) {
	...
 }catch(eccezione2 e2) {
	...
 }catch(eccezione3 e3) {
	,,,,
 }
}
metodo1() throws eccezione1 { 
 ...
 istruzione1 //espone eccezione1
 ...
}
metodo2() throws eccezione2, eccezione3 {
 .... 
 metodo3() 
 istruzione2 //espone eccezione2
 ....
}
metodo3() throws eccezione3 { 
//throws vuol dire lasciami trovare per eccezione3
 ...
 istruzione3 //espone eccezione3
 ...
}
Se la nidificazione dei metodi ti porta a fare throws di molte
eccezioni, al limite potresti qua e la "assorbire" qualcuna delle
eccezioni con dei try/catch, ma SOLO per generare una nuova eccezione
già gestita e non per far sparire l'errore come fa il "resume next" di
vb che è una vera porcheria.
Al limite puoi assorbire con un catch vuoto eccezioni attese, come ad
esempio: eccezione "saldo a zero", va bene, grazie proseguo
e non fare finta che un erorre non ci sia stato tanto perchè non si sa
come gestirlo senza incasinare il codice.
Ad esempio nell'esempio di cui sopra, se non vuoi nidificate il throws
di eccezione2, potresti nel metodo2 fare cosi:
metodo2() throws eccezione3 {
 .... 
 metodo3()
 try {  
    istruzione2 //espone eccezione2
 }catch(eccezione2 e) {
   throw new eccezione3("sjsjsjs"+eccezione2.toString())
 }
 ....
}
in questa maniera chi usa il metodo2 deve gestire o meglio far passare
con throws solo eccezione3 e non anche eccezione2 che viene assormita
generando però una nuova eccezione3
nel caso in cui la istruzione2 generi l'eccezione2, l'esecuzione del
metodo2 si interromperà grazie al throw new...
addirittura (non lo consiglio) potresti scrivere sempre merodi che
usano throws Exception (il padre delle eccezioni così le intercetti
tutte con una sola voce) e gestire una sola catch(Exception e) ad
inizio processi
Ricorda sempre di inserire nella catch ad inizio processi un 
println(e.toString() ); //mostra errore o on jdialog....
e.printStackTrace() //stampa trace, magari im un log...
in modo che puoi sapere dove si è verificato l'errore
ciao

 verificato l'errore.
Intercetta l'eccezione in modo che lo faccia. Se l'istruzione successiva 
è fuori dal blocco try/catch può essere eseguita senza problemi.

 perchè a gestisce le eccezioni saranno SOLO i metodi che hanno datao
... scusa ma mi fermo qui. Caro Luciano, scusami, non mi è mai piaciuto 
"vantarmi", ma ho una certificazione Java alle spalle e un'altra in 
preparazione, nonché qualche anno di esperienza su applicazioni 
enterprise dove l'affidabilità è decisamente un punto critico.
Ti posso assicurare che hai scritto una marea di ... inesattezze.
Ti consiglio, nell'ordine, di rivederti: i fondamenti della 
programmazione, Java, la tua filosofia.
Senza rancore :)
