Newsgroup: it.comp.java
Titolo: [Eccezioni] RuntimeException to Cheked Exception

Ciao
Mettiamo che uso una libreria che genera delle RuntimeException.
Mettiamo che io voglia nella mia applicazione cambiare questa gestione
e farle gestire come Cheked Exception.
Esiste un qualche modo/strategia/trucco brutto sporco e cattivo per
fare ciò?
(con AspectJ si può fare l'esatto contrario con le softening
exception...mumble mumble).
Icaro

 fare ci�?
Non so darti una rispostacerta, ma vedi se questo 
http://www.fgasoftware.com/articoli/exception-chaining-in-java/
 pu� 
esserti utile (ripeto, non ne sono sicuro: ho dato solo uno sguardo 
rapido) la parte sulle Exception Chaining

 rapido) la parte sulle Exception Chaining
Ti ringrazio del link, ma non vi sono dettagli rispetto a quello che
mi serve.
Il punto è che io dovrei in qualche modo sovvertire una catena di
ereditarietà. Ho una classe Ex che estende RuntimeException che
estente Exception e io vorrei invece che che si comportasse come
Exception, ovvero obbligasse al catch o al throws di Ex.
Icaro

 Icaro
uhm... catturi la runtime exception? :D
nulla ti vieta di scrivere una cosa del genere, senza tirare nel mezzo
AspectJ:
try {
   ...
} catch (NullPointerException ex) {
   //gestisci l'eccezione
}
-- 
Scientology: se la conosci la eviti, se la conosci non ti uccide...
http://xenu.com-it.net
 - 
http://xenu.freewinds.cx
 - 
http://www.xenu.net
(per rispondere personalmente leva IlDitoDalCulo)
---> 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 <---

 }
Ma questo è tutt'altro rispetto a quello intendevo.
Io vorrei che chi utilizza le classi siano "obbligati" ad
"preoccupartsi" di una specifica eccezione (come ad esempio di una
ParseException) anche se chi l'ha sviluppato la libreria ha dichiarato
quella eccezione come Runtime. Il metodo che suggerisci, per quanto
funzionante, rimanda all'intuizione dello sviluppatore il decidere se
preoccuparsene o no.
Icaro

 dello sviluppatore il decidere se preoccuparsene o no.
E tutto il codice della libreria che sorvola bellamente su 
quell'eccezione, come si fa?
Non credo sia fattibile quello che dici, neanche con AspectJ. Ma di byte 
code non me ne intendo molto quindi potrei anche sbagliarmi.
Piuttosto trovo strana questa necessità di voler tornare alle checked 
exception, quando la maggior parte delle librerie e framework stanno 
fuggendo a gambe levate da esse trovandole inutili e scomode.

 fuggendo a gambe levate da esse trovandole inutili e scomode.
Dici? Si, solitamente è più comodo non dover gestire alcune eccezzioni
esplicitamente, ma solo quando realmente non vogliamo/possiamo
preoccuparcene.
In altri casi a me pare faccia comodo forzare gli utilizzatori a
rendersi conto di cosa potrebbe andare storto. E come si dice in
questi casi : IMHO!

 farle gestire come Cheked Exception. Esiste un qualche
Qualcosa ti impedisce di "wrappare" le runtimeexception dentro le tue 
checked? Cioe':
try{
...
}catch(RuntimeException e){
  throw new MyCheckedException(e);
}
Naturalmente gli utenti non devono usare direttamente la libreria ma il 
tuo wrapper...
pole
-- 
www.ammentos.org


Penso mi sfugga qualcosa. Cosa intendi per wrap? Dovrei fare un metodo
copia di ogni metodo della libreria che lancia Runtime?
Vorrei qualcosa di più "comodo" come ad esempio estendere queste
RuntimeException Eliminando la loro capacità di non essere Checked.
(il contrario di quello che fa RuntimeException rispetto a Exception),
ma non so come sia possibile ottenerlo.

 e farle gestire come Cheked Exception.
Ciao GiovaneInca,
ti consiglio di NON usare le checked exception, come dice anche Bruce
Eckel (Thinking in Java)
http://www.mindview.net/Etc/Discussions/CheckedExceptions
Luca