Newsgroup: it.comp.java
Titolo: Gestione delle eccezioni in applicazioni java a livelli

Salve, devo scrivere una piccola applicazione in java con la classica 
architettura a 3 livelli:
interfaccia grafica - dominio - sorgente dati
Il problema � su che strategia adottare per gestire le eccezioni: ad es. se 
voglio salvare un record su un database, attraverso l'interfaccia grafica i 
dati vengono trattati dal dominio e passati alla sorgente dati che apre una 
connessione al database per eseguire una query insert.
Ma nell'eventualit� che venga sollevata un'eccezione "SQLException" come mi 
conviene gestirla?
Chiamare una finestra di dialogo dallo strato pi� basso per notificare 
l'utente non mi sembra una buona idea dato che questo strato non deve 
occuparsi della grafica; in questo caso dovrei far passare l'eccezione agli 
strati superiori con la clausola throws nelle intestazioni dei metodi con lo 
svantaggio di dover gestire tutte le eccezioni nella classe che gestisce 
l'interfaccia grafica, perch� per ogni eccezione l'utente dev'essere 
notificato.
Cosa dovrei fare?
Spero di aver chiarito il problema.
Grazie.
 

 mi conviene gestirla?
in un modello a tre livelli si suppone che a livello pi� basso ci sia il 
mero accesso al database, mentre a livello superiore ci sia (fra 
l'altro) la gestione delle transazioni. come minimo le eccezioni db non 
devono essere nascoste ai manager.

 conviene gestirla?
SQLException ha senso solo al livello piu' basso, che tu definisci
"sorgente dati".
A livello "dominio" quell'SQLException assume un nuovo significato:
l'operazione logica che stavi eseguendo e' fallita. Visto che la tua
operazione era il savataggio di un record (inserimento di un "dato")
allora probabilmente dovrai generare una InserisciDatoException.
A livello "grafico" non ti interessa sapere che il database ha
fallito, ma ti interessa solo segnalare all'utente che c'e' stato un
generico problema, chiamiamolo "QualcosaEAndatoStortoException".
Quest'ultima eccezione puo' essere gestita in modo quasi automatico
dal framework che utilizzi per implementare il paradigma MVC.
Cosi' facendo definisci una dettagliata struttura gerarchica di
eccezioni che ti aiuta immensamente quando devi riuscire a risolvere
un problema leggendo un semplice stacktrace.
Ecco un codice d'esempio:
//Questo e' il livello "dominio"
public void inserisciDato( Dato dato ) throws InserisciDatoException{
  try{
    ...
    eseguiInsert( ... ); //Qui chiamo il livello "sorgente dati"
  }catch( SQLException e ){
    throw new InserisciDatoException( "Errore nell'inserimento del
dato", dato, e );
  }
}
//Questo e' il livello "grafica"
public void azioneInserimentoDaInterfacciaGrafica( Params params )
throws QualcosaEAndatoStortoException{
  try{
    ...
    inserisciDato( dato );
  }catch( InserisciDatoException e ){
    throw new QualcosaEAndatoStortoException( "Impossibile inserire
l'oggetto.", params, e );
  }
}
E la QualcosaEAndatoStortoException deve essere riconosciuta dal
framework in modo che questo sara' in grado di visualizzare un errore
del tipo "Il sistema non e' al momento disponibile" oppure "Si e'
verificato un errore imprevisto".
Questo sistema ovviamente va usato solo per le eccezioni per le quali
non esiste una soluzione applicativa. Se una soluzione esiste allora
l'eccezione non va rilanciata fino ad essere visibile all'utente, ma
va risolta prima.
Tornando al discorso della gerarchia delle eccezioni, hai il vantaggio
che in un'applicazione piu' complessa la (ad esempio)
InserisciDatoException potrebbe derivare non solo da una SQLException
ma anche da altre eccezioni, e lo stesso discorso vale per la
QualcosaEAndatoStortoException. Cosi' facendo con una sola eccezioni
riesci a gestire piu' casi d'errore simili che devono essere trattati
allo stesso modo dal layer applicativo superiore.
--
SoulSpirit