Newsgroup: it.comp.java
Titolo: implementare eccezioni: best practice

Sto creando una API e sto ora ripassando tutto il codice alla ricerca di
possibili errori implementando le relative eccezioni da lanciare.
Volevo sapere cosa "è costume" mettere nella classe di eccezione, oltre
alla classica stringa con la descrizione.
Non so se sono stato spiegato...
Alex.
-- 
___________________________________________________________
a p bertolini
(
www.webwarrior.org
)

 Non so se sono stato spiegato...
Non ti sei spiegato.


Groan :-( Scusate, riprovo
La classica eccezione di esempio è del tipo:
class MyException extends Exception {
  public MyException() {}
  public MyException(String msg) { super(msg); }
}
cui poi uno può aggiungere un "printStackTrace()" in modo da poter
identificare la sorgente dell'eccezione.
Volevo sapere se nell'uso di tutti i giorni, per applicazioni serie e
complesse, la classe di eccezione (o il metodo che la "lancia") segue dei
formalismi particolari (per esempio l'iscrizione in un log, l'impostazione
di un qualche flag, non so...).
Ecco, qual'è il pattern di una classe che estende Exception?
Grazie


Ciao, APB!
Il giorno 04/06/2004 alle ore 00:40 hai scritto:
 A> Volevo sapere se nell'uso di tutti i giorni, per applicazioni serie e
 A> complesse, la classe di eccezione (o il metodo che la "lancia") segue
 A> dei formalismi particolari (per esempio l'iscrizione in un log,
 A> l'impostazione di un qualche flag, non so...).
Se dai un'occhiata alle varie eccezioni della libreria standard potrai
notare come in realta' non si deve dichiarare piu' di quanto non metta a
disposizione la classe base Exception. Quello che si dovrebbe fare e' creare
diverse classi a seconda del tipo di eccezione sollevata. Per esempio un
parametro non valido dovrebbe sollevare una InvalidParameterException, un
errore di scrittura su file dovrebbe sollevare WriteException, ecc. in modo
che catturandole nel blocco try/catch sai gia' che genere di errore hai e
come gestirlo e se vuoi visualizzarlo basta un printStackTrace oppure un
getMessage().
Al contrario se implementi un'unica classe dovrai poi aggiungere un metodo
per distinguere il tipo di errore. In realta' questo non e' poi cosi' grave
ma direi che il primo metodo e' piu' nello "spirito" di Java e
dell'object-oriented.
Bye
-- 
Fear leads to anger, anger leads to hate, hate leads to suffering.
http://www.maccasoft.com

 Ecco, qual'è il pattern di una classe che estende Exception?
L'unica cosa che accade *sempre* :) e' di generare un'eccezione 
specifica come conseguenza di un'altra (la "causa") di piu' basso 
livello (quasi sempre accade perche' si sta implementando un'interfaccia
che definisce quali checked exception un metodo puo' sollevare, ma 
l'implementazione solleva eccezioni checked di classe diversa). Succedeva 
talmente spesso (con centinaia di "ChainedException" ricreate per 
ogni progetto) che alla Sun hanno pensato bene di implementare 
la cosa direttamente in Throwable/Exception/RuntimeException, 
che dalla 1.4 espongono anche costruttori con (Throwable t) e (String msg, Throwable t)
e hanno un metodo getCause().
Per il resto, se ne parlo' un po' qualche tempo fa - una mia opinione, ad esempio, a 
http://groups.google.com/groups?selm=Xns93CDB55664F9Ccristianoxtractorcom%40130.133.1.4&output=gplain

 Ecco, qual'è il pattern di una classe che estende Exception?
In generale, estendo i constructor di Exception che richiedono un 
messaggio testo e/o una Throwable come "causa" principale dell'errore.

Grazie a tutti!
