Newsgroup: it.comp.java
Titolo: Gestione Eccezioni centralizzata?

Salve a tutti ragazzi,
sono un newbbo in ambito java e provengo dal Vb, quindi niente a che vedere 
con java.
il mio dubbio č il seguente:
Sto scrivendo la mia prima applicazione java (non web ma stand alone).
Con altri linguaggi ero abituato a gestire gli errori delle mie applicazioni 
in maniera centralizzata, ovvero scrivendo una classe che gestisse tutti i 
tipi di errore e, in caso di errore, demandavo il tutto ad essa.
A quanto vedo,perň,  sbirciando un po' i pezzi di codice in rete, in java la 
gestione delle eccezioni č realizzata all'inteno della classe/metodo di 
interesse (nel quale viene scatenata l'eccezione/errore).
C'č un motivo particolare per ciu viene fatta questa scelta?
Concettualmente quindi , anche pensando ad un'eventuale applicazione web, č 
giusto o sbagliato , secondo voi centralizzare la gestione delle eccezioni?
Grazie per l'aiuto.
FC 

Non è affatto vero quello che scrivi.
Decidere se gestire o rilanciare l'eccezione è a carico dello
sviluppatore che può decidere nel primo caso di implementare un blocco
try-catch, nel secondo di utilizzare il throws

 giusto o sbagliato , secondo voi centralizzare la gestione delle eccezioni?
Secondo me si, e anche secondo gli autori di framework come Spring (ad
esempio). Il punto è un'altro: ci sono casi (vedi SQLException) in cui
se ti fai sfuggire l'eccezione perdi la possibilità di liberare le
risorse. In C# c'è il concetto di Dispose che farà schifo ma risolve
il problema, in Java devi comunque prevedere un try/finally nel punto
in cui prevedi possa essere scatenata l'eccezione.

 writes:
F> Concettualmente quindi , anche pensando ad un'eventuale
F> applicazione web, è giusto o sbagliato , secondo voi centralizzare
F> la gestione delle eccezioni?
La gestione delle  eccezioni in Java segue la  filosofia di permettere
di  decidere  a  quale  livello  dell'applicazione  vanno  gestite  le
eccezioni, se è  giusto gestire la cosa in locale oppure  è il caso di
farla risalire lungo la catena di chiamate, nel punto dove è veramente
il caso che la cosa sia gestita.
Infatti la gestione  può permettere di ricuperare la  situazione e far
continuare  l'elaborazione,  niente a  che  vedere  con  gli on  error
goto...
-- 
 /\            ___
/___/\__|_|\_|__|___Gian Uberto Lauri_____________________
  //--\ | | \|  |   Integralista GNUslamico  
\/		    e allevatore di bug da competizione

 Concettualmente quindi , anche pensando ad un'eventuale applicazione web, è 


 giusto o sbagliato , secondo voi centralizzare la gestione delle eccezioni?
Nella filosofia Java, come in tutti i linguaggi fortemente tipizzati, è 
assolutamente giusto in quanto costringe a prendere in considerazione, 
in fase di programmazione, la maggior parte dei problemi che possono 
verificarsi ad ogni livello nella catena delle chiamate senza dover 
controllare la validità dei valori ritornati dalle funzioni (che sarebbe 
addirittura più palloso).
Inoltre una gestione localizzata spinge alla creazione di programmi 
molto più solidi a meno che uno non preferisca comunque la gestione 
centralizzata  (cosa sempre possibile).
Rispondi alla seguente domanda: come fai ad accedere alle variabili 
locali di una funzione o di un oggetto con la gestione centralizzata?
Io utilizzo java anche per applicazioni non web e, dal momento che ormai 
l'ardware scavalca il collo di bottiglia tipico dei semicompilati, è 
molto più divertente rispetto all'utilizzo dei compilati....
Appena hai imparato la programmazione nuda e cruda passa ad Eclipse (con 
   miglior gestione dei progetti) o NetBenas (con miglior GUI Builder).

Ok adesso la situazione mi è più chiara.
In altre parole posso decidere di :
1) rimediare (quando è possibile) il comportamento anomalo del programma a 
seconda dell'eccezione riportata, in modo da mantenere viva la mia 
applicazione rendendo il tutto trasparente all'utente (gestione locale 
try/Catch);
2)  segnalare il malfunzionamento della mia applicazione con un messaggio di 
errore, ed eventualmente la fonte ed il pezzo di codice che ha generato 
l'errore/Eccezione, senza possibilità di rimediarvi e terminando 
l'operazione appena interrotta dall'anomalia (in questo caso posso 
utilizzare una gestione centralizzata) ;
Sarebbe bene quindi utilizzare tutti e due i metodi , a seconda che l'errore 
sia rimediabile o meno.
Spero di aver tratto le giuste conclusioni.
Grazie comunque a tutti per il prezioso aiuto.
By By
CF

In genere, in grosse applicazioni si tende a wrappare qualsiasi
eccezione in una personalizzata in modo da non avere clausole throws
lunghissime (ed anche per evitare un lunghissimo blocco try-catch al
main).
Anche in questo caso, soprattutto se sono checked, dovrai comunque
scrivere blocchi try-catch neei cui catch ci saranno tanti throw

 writes:
F> Ok adesso la situazione mi è più chiara.  In altre parole posso
F> decidere di :
F> 1) rimediare (quando è possibile) il comportamento anomalo del
F> programma a seconda dell'eccezione riportata, in modo da mantenere
F> viva la mia applicazione rendendo il tutto trasparente all'utente
F> (gestione locale try/Catch);
Va detto che ci sono tre tipi di eccezioni:
* Le  "sei stato  mona",  non  sono verificate  dal  compilatore e  si
  verificano quando  il programmatore NON  ha fatto quello  che doveva
  fare.  In produzione  NON dovrebbero  presentarsi  (puntatori nulli,
  indici degli array fuori dai limiti)...
* Gli  errori,  beh,  quelle  sono  situazioni a  cui  è  praticamente
  impossibile porre rimedio. Si può provare a limitare i danni, questo
  si, cercando di salvare il salvabile e chiudere dolcemente ciò che è
  stato aperto
* Le eccezioni con causa esterna, come le IOException, dovute al fatto
  che non siamo in un mondo  ideale e qualcosa fuori dal programma può
  andare male. In  questi casi non è bello  far morire l'applicazione,
  ad  esempio se non  c'è il  collegamento di  rete l'utente  può fare
  qualcosa (connettersi,  verificare che  il cavo di  rete non  si sia
  staccato...).  Il livello a  cui gestirla  dipende dall'architettura
  dell'applicazione.
F> 2) segnalare il malfunzionamento della mia applicazione con un
F> messaggio di errore, ed eventualmente la fonte ed il pezzo di
F> codice che ha generato l'errore/Eccezione, senza possibilità di
F> rimediarvi e terminando l'operazione appena interrotta
F> dall'anomalia (in questo caso posso utilizzare una gestione
F> centralizzata) ;
Questo usualmente  si fa  e mostrando un  messaggio (che  qui vogliono
meno spaventoso possibile) e mettendo a  log la cosa per i tecnici che
ci devono mettere le mani.
La gestione  centralizzata in  Java non è  che abbia molto  senso, gli
oggetti onniscenti rischiano di violare l'incapsulamento.
(suggerimento:  DIMENTICATI  il VB  6,  la  sua  object orientation  è
ridicola  e programmare  in Java  come in  VB vuol  dire  fare cattivo
codice, il VB dot niet è un Java con una brutta sintassi :) :) :) )
F> Sarebbe bene quindi utilizzare tutti e due i metodi , a seconda che
F> l'errore sia rimediabile o meno.  Spero di aver tratto le giuste
F> conclusioni.
Se  l'errore non  è  rimediabile c'è  una centralizzazione  implicita,
risali fino al primo metodo invocato dalla JVM e muori :).


 codice, il VB dot niet è un Java con una brutta sintassi :) :) :) )
è chiaro. Mi rendo conto che il vb 6 non è un linguaggio OO, e che il 
vb.net
 
è stasto scopiazzato dal java, ma
dopo 5 anni di vb 6 , alcune "brutte abitudini" ti vengono naturali, ed 
abbandonarle non sarà cosa facile, ma ce la metterò tutta! ;-)
Mi rinquora il fatto di muovermi verso un VERO linguaggio di programmazione.
thx
 

 * Le  "sei stato  mona",  non  sono verificate  dal  compilatore e  si
E' la classificazione ufficiale Sun ? :-)
bye
DKano

 codice, il VB dot niet è un Java con una brutta sintassi :) :) :) )
Beh, ricordiamoci anche che Vb.net non è Vb6 e anche Java ha i suoi
scheletrini nell'armadio...

> non sono verificate dal compilatore e si
D> E' la classificazione ufficiale Sun ?
Probabilmente lo  è stata  prima che intervenisse  l'ufficio marketing
(per loro dare del mona al cliente è disdicevole)


> codice, il VB dot niet è un Java con una brutta sintassi :) :) :) )
VV> Beh, ricordiamoci anche che Vb.net non è Vb6 e anche Java ha i
VV> suoi scheletrini nell'armadio...
Non giudico  Java perfetto,  ho letto  ieri un pezzo  di un  tizio che
lavora (dall'inizio  a quanto pare)  per Amazon e condivido  molte sue
critiche a Java.
Vb dot niet  è "un Java con una bruta sintassi"  perché ne hanno fatto
un linguaggio OO (avevo un amico  in MS, ora l'amico c'è ancora ma non
in  MS,  e mi  disse  che  "vb era  andato  molto  verso  java", e  la
conversione  automatica da VB6  a dot  niet era,  almeno quando  la ho
provata, una chimera.


 Vb dot niet  è "un Java con una bruta sintassi"
Al di là degli opinabili aspetti denigratori, questi paragoni lasciano
il tempo che trovano. Io lavoro  negli ultimi tempi prevalentemente in
C#, quindi in .NET, dopo essermi certificato Java. Vb.NET non lo uso e
non lo conosco, ma siccome sento spesso affermazioni tipo "Pincopallo
è copiato da Java", "Pallopinco è un java più brutto" e cose simili,
mi chiedo sempre su che basi si fanno queste affermazioni. Su basi
pratiche mi sembra parecchio strano, visto che passando da un ambiente
all'altro trovo delle differenze basilari che vanno ben oltre gli
elementi di semantica. Tanto per essere espliciti, in Java si programma
in modo completamente diverso da .Net; per esempio in questo thread
stiamo parlando delle eccezioni, se trattassimo lo stesso argomento in
.Net faremo tutto un'altro ragionamento.
Che Vb.NET sia andato verso Java sarà un impressione, impressione che
non ho nemmeno di C# che, a detta di tanti che l'hanno visto con la
coda dell'occhio, sarebbe tal quale sputato.

> Vb dot niet č "un Java con una bruta sintassi"
VV> Vb.NET non lo uso e non lo conosco,
Lo ho provato, concettualmente č  un linguaggio OO, mantiene la brutta
sintassi di VB. 
VV> ma siccome sento spesso
VV> affermazioni tipo "Pincopallo č copiato da Java", "Pallopinco č un
VV> java piů brutto" e cose simili, mi chiedo sempre su che basi si
VV> fanno queste affermazioni.
Mah, quando  MS ha  presentato a  Milano dot niet  ha fatto  una bella
convention dove hanno pure mostrato il loro bytecode... Puoi chiederlo
ai miei  colleghi se il mio  commento ricorrente non era  "ma questo č
preso da  Java". Certo, era  una presentazione, quindi non  sono stati
approfonditissimi.
Per il resto  non mi ha interessato piů di tanto,  adesso che c'é Mono
che  lato server dovrebbe  essere ben  compatibile con  la controparte
Microsoft,  cosa che  mi permetterebbe  di lavorare  "come dico  io" e
quindi potrei riprenderlo. Altrimenti preferisco dare un occhio a Ruby
o aprire fiunalmente il librone di Steele sul LISP.
VV> Tanto per essere espliciti, in Java si programma in
VV> modo completamente diverso da .Net; per esempio in questo thread
VV> stiamo parlando delle eccezioni, se trattassimo lo stesso
VV> argomento in .Net faremo tutto un'altro ragionamento.
Why, niete try/catch/finally ? 


 l'esito dell'operazione ma non lo stato del programma stesso.
Non sono sicuro di aver capito cosa intendi con stato del programma.
Sono però certo che molto di noi hanno beccato almeno i
NullPointerException anche per errori di progettazione/analisi oltre
che per mancanza di robustezza (della serie, quell'oggetto non potrà
mai e poi mai essere null).
Non si tratta quindi di un semplice errore di programmazione .
In quel caso non basterà una semplice if per sistemare il tutto....

 writes:
p> Vincent Vega wrote:
p> Sono però certo che molto di noi hanno beccato almeno i
p> NullPointerException anche per errori di progettazione/analisi
p> oltre che per mancanza di robustezza (della serie, quell'oggetto
p> non potrà mai e poi mai essere null).  Non si tratta quindi di un
p> semplice errore di programmazione .  In quel caso non basterà una
p> semplice if per sistemare il tutto....
Se intendi come programmazione solo la scrittura del codice può essere. 
Ma nel caso della NullPointerException hai due casi:
   L'oggetto dipende dal programma che lo ha generato
   L'oggetto non dipende dal programma che lo ha generato (caso
   tipico, la sessione HTTP quando usi
   HttpServletRequest.getSession(false) e la sessione è scaduta)
Nel  primo caso  o l'errore  può  essere nell'analisi  ma anche  nella
codifica del codice "a monte" del metodo chiamato. In ogni caso c'è da
mettere mano  al codice,  e nessuno pensava  che il  codice malscritto
necessitasse di un semplice if...
Nel secondo caso c'è da gestire l'evenienza, che sia documentata o no.
Anhce qui può non bastare il semplice if.
