Newsgroup: it.comp.java
Titolo: Aiuto non so quale eccezione lanciare

Devo lanciare un'eccezione quando un particolare metodo viene lanciato e 
allo stesso tempo una variabile (indicante lo "stato" dell'oggetto) 
assume un certo valore.
Mi spiego con un esempio:
se k = 1 allora posso richiamare il metodo,
se k = 2 il metodo non si può utilizzare e si deve perciò lanciare 
l'eccezione.
Esiste già un'eccezione creata allo scopo?
Spero di essere stato chiaro nella spiegazione.
Andrea

 writes:
ib> Devo lanciare un'eccezione quando un particolare metodo viene
ib> lanciato e allo stesso tempo una variabile (indicante lo "stato"
ib> dell'oggetto) assume un certo valore.  Mi spiego con un esempio:
ib> se k = 1 allora posso richiamare il metodo, se k = 2 il metodo non
ib> si può utilizzare e si deve perciò lanciare l'eccezione.  Esiste
ib> già un'eccezione creata allo scopo?
/**
 * class StatoDelloOggettoNonValidoException.
 *
 * Forse per caso pensi che alla Sun abbiano voglia di pensare a tutte
 * le cose che possono andare storte in uno qualsiasi dei programmi
 * possibili? 
 *
 * Pensaci bene, non ha senso. Loro hanno pensato le eccezioni per
 * quello che può andare male nel codice che hanno prodotto loro, gli
 * utenti, per quello che può andare male nel loro codice, utilizzino
 * delle eccezioni custom create estendendo Exception. Mi pare che la
 * cosa sia anche spiegata nei libri...
 *
 * Questa. E' distribuita sotto GNU GPL quindi non è includibile in un
 * programma  non distribuito  con tale  licenza. Ma  l'autore  non si
 * arrabbia se te la riscrivi (no, niente copia e incolla!) :).
 *
 * Created: Wed Feb  1 16:11:27 2006
 *
 * @author <a href="mailto:
sa...@spammer.impiccati.it
">Gian Uberto Lauri</a>
 * @version 1.0
 */
public class StatoDelloOggettoNonValidoException 
  extends Exception {
  public StatoDelloOggettoNonValidoException(){ 
    super();
  }
  public StatoDelloOggettoNonValidoException(String msg){ 
    super(msg);
  }
 
  public StatoDelloOggettoNonValidoException(String msg, 
					     Throwable causa){ 
    super(msg, causa);
  }
  public StatoDelloOggettoNonValidoException(Throwable causa) { 
    super(causa);
  }
}
-- 
 /\            ___
/___/\__|_|\_|__|___Gian Uberto Lauri_____________________
  //--\ | | \|  |   Integralista GNUslamico  
\/		    e allevatore di bug da competizione

 Esiste già un'eccezione creata allo scopo?
Io me ne aspetterei una che estende questa:
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/IllegalStateException.html
--
Marco

 Marco
Occhio che è una RuntimeException

 Esiste già un'eccezione creata allo scopo?
java.lang.IllegalStateException può essere congruente. E' una
RuntimeException.
Altrimenti niente vieta che te ne crei una specifica.

 
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/IllegalStateException.html
 
Esattamente quello che cercavo. Grazie!
Andrea

> un'eccezione creata allo scopo?
VV> java.lang.IllegalStateException può essere congruente. E' una
VV> RuntimeException.  Altrimenti niente vieta che te ne crei una
VV> specifica.
Io sarei per dire "c'è  qualcosa che suggerisce che potrebbe essere il
caso te ne crei una specifica".
L'eccezione non è tra le checked e questo, IMHO, richiede che si pensi
un attimo alla situazione. Se  ci si trova nella situazione di "pirla,
hai  scritto il  codice  usando l'oggetto  in  modo sbagliato"  allora
l'eccezione unchecked  va bene  in quanto l'oggetto  va usato  in modo
corretto, ed in quel caso non  ci sono problemi - quindi perché perder
tempo con  il meccanismo di try/catch  ? -. Se  al programmatore viene
fuori l'eccezione in fase di  prova, si riscriva il codice usando bene
l'oggetto.
Ma se  lo stato dell'oggetto  non dipende solo  dall'uso che ne  fa il
programmatore, come  nel caso degli accessi  al file system  in cui ci
possono essere  problemi scorrelati con la correttezza  del codice del
programma,  allora  è  il  caso  che l'eccezione  sia  checked  ed  il
programmatore  si  prenda  carico  di provvedere  alle  operazioni  da
intraprendere in caso di guai.
In  ogni caso  non  sarebbe male  estendere IllegalStateException  per
migliorare la significatività della cosa.


 un attimo alla situazione. 
Ci sarebbe da aprire un dibattito e adesso non ne ho voglia :-) Fermo
restando che se fosse per me tutte le eccezioni dovrebbero essere
unchecked, quella condizione dovrebbe sollevare una eccezione solo se è
un errore e non per un semplice controllo di stato. Quindi "costringere"
il chiamante a trappare questo tipo di eccezioni è una brutta abitudine
in cui, purtroppo, i javisti cadono sovente :-)

  * class StatoDelloOggettoNonValidoException.
LOL :-D
-- 
Giambo - Occhio al filtro antispam _e_ alla whitelist !

 ha scritto nel messaggio
news:43e0ce47$0$22090$4faf...@reader1.news.tin.it...

Scusa una curiosità, ma perchè deve proprio lanciare un
eccezione?
non hai pensato a qualche altro sistema per aggirare
l'ostacolo, che ne sappia io
le eccezioni, correggimi se sbaglio, in qualche modo cercano
di porre rimedio
a situazioni estreme, tu le usi quasi al posto di un IF!!!
da come hai postato la cosa
si direbbe così.
Sicuro che una IF non ti risolve il problema?

 writes:
VV> Fermo restando che se fosse per me tutte le eccezioni dovrebbero
VV> essere unchecked, quella condizione dovrebbe sollevare una
VV> eccezione solo se è un errore e non per un semplice controllo di
VV> stato. 
Le eccezioni checked, a parer mio, servono, e servono quando ci sono
eventi che non dipendono dal programma.
Le  altre sono  d'accordo  anche io  che  dovrebbero essere  unchecked
(pirla di un programmatore, sono  l'eccezione che ti sta ricordando di
scrivere codice stupido).
VV> Quindi "costringere" il chiamante a trappare questo tipo di
VV> eccezioni è una brutta abitudine in cui, purtroppo, i javisti
VV> cadono sovente :-)
Premesso  quanto sopra,  mi trovi  d'accordo. Costringere  la  gente a
mettere un try-catch per cose che dovrebbe aver sotto controllo avendo
responsabilità del codice  non è una bella cosa.  Anche perché cosa si
mette  nella catch ad  un eccezione  la cui  semantica più  profonda è
"Pirla di un programmatore, hai scritto del codice stupido" ? :) :)


 quasi al posto di un IF!!!
Allora in Java e in C++ (per dirne due) è spesso considerata preferibile
la regola LBYL. Quindi in generale è il caso di usare un if invece di
un'eccezione in situazioni del tipo
try{
   a.doSomething();
} catch (YouShoudNotHaveDoneThatException){
   // baz...
}
sia meglio 
if (a.youCanDoIt()){
   a.doSomething();
}
Questo è specialmente vero in casi in cui il codice di cui sopra è
eseguito molto spesso (lanciare un'eccezione in Java ha un costo
nettamente superiore ad un if e in C++ ancora maggiore).
Tuttavia se effettivamente l'eccezione è molto rara, anche per ragioni
prestazionali potrebbe convenire fare con il try (ma qui si entra nel
campo "ottimizzazione", che è pelosissimo...). Oppure anche una
considerazione che faccio dopo potrebbe fare propendere per un EAFP.
Altri linguaggi ancora preferiscono un approccio EAFP (in generale). A
me personalmente piace di più. Trovo che complessivamente il codice sia
*molto* più leggibile (nei casi in cui la semantica è devo fare qualcosa
che però potrebbe non potersi fare in certi casi). Queste ovviamente
sono "finezze" e devono essere comunque integrate con:
1) problemi prestazionali
2) background degli altri programmatori
Ovviamente se gli altri con cui lavoro si aspettano LBYL e io gli do
EAFP per loro *non* sarà particolarmente chiaro (anche se sicuramente
più chiaro che infilare del LBYL quando uno si aspetta EAFP).
Se i motivi (e i controlli) che possono rendere a.doSomething non
fattibile sono molti, diventa sicuramente più chiaro un EAFP (oltre che
porre meno problemi in caso di modifica delle condizioni al contorno,
aggiungere o togliere test):
if( !(a.tooHot()  || 
      a.tooCool() || 
      a.tooBig    || 
      a.tooSmart() ) )[
    a.doSomething();
}
rispetto a 
try{
    a.doSomething();
} catch (InvalidState){
   // baz
}
Non solo... il test di validità viene encapsulato nel metodo. Ovvero il
programmatore che lo usa deve sapere quali test deve fare, invece con il
try il programmatore deve solo sapere che qualocosa può andare male,
senza necessariamente sapere cosa.
  Fra le altre cose diventa impossibile scordarsi di fare un singolo
test. Basta sapere che il metodo lancia un'eccezione (e in generale in
Java è probabile -- nel caso che non sia runtime, frequente -- che sia
il compilatore stesso a dircelo).
Last but not least, un motivo di "pulizia del codice/ottimizzazione". I
n alcuni/molti casi una parte del codice per fare il controllo e per
eseguire il metodo sono in comune. Quindi si ha una doppia esecuzione
con l'if, invece con il try no.
Questo può essere anche non essere trascurabile.
Poi se ci mettiamo in ambienti pesantemente multiprogrammati avere tutto
in un unico metodo rende più facile l'eventuale gestione di lock e
simili, invece che doverli esplicitamente gestire al di fuori dei metodi
(in generale non basta avere locking per il check e per l'azione, in
quanto nel frattempo potrebbe essere cambiato lo stato, è necessario che
lo stato non cambi fra il check e l'azione).
  Ovviamente organizzandosi bene questi non sono problemi "veri", ma
resta comunque che può essere più comodo fare un unico metodo "esposto"
che fa l'azione e in caso di problemi lancia l'eccezione.
-- 
Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it.
    - Brian W. Kernighan

 wrote:
|
| > in qualche modo cercano di porre rimedio a situazioni
estreme, tu le usi
| > quasi al posto di un IF!!!
|
| Allora in Java e in C++ (per dirne due) è spesso
considerata preferibile
| la regola LBYL. Quindi in generale è il caso di usare un
if invece di
| un'eccezione in situazioni del tipo
|
Ma che mi stai facendo l'esame a ciò che scrivo?
Se lui DEVE lanciare un eccezione, e va beh amen
facciamogliela lanciare, ma leggendo libri e manuali
sul Java non ho MAI letto che l'uso delle eccezioni sia
preferibile in nessun caso, salvo ovviamente la gestione
forzata di quelle controllate, da come lui ha posto il
problema sembrerebbe che l'uso dell'IF sia una soluzione!
Mai letti esempi in cui l'uso del try catch sia una pratica
di programmazione!!
Anzi taluni di questi scrittori lamentano proprio questo
fatto tra la moltitudine dei programmatori, e cioè che la
gestione
delle eccezioni sia un po' trascurata, ma un po'!! non
decisamente sottovalutata!
Le eccezioni non controllate devono essere usate tutte le
volte in cui si prevede la possibilità che qualcosa vada
storto!
non CERTAMENTE al posto di un IF, se l'if risolve meglio il
problema, tanto è vero che io in ultimo ho scritto
"sei sicuro che un IF non ti risolve il problema" non che
non debba considerare assolutamente l'eventualità di usarle,
specie
se DEVE ;)  understood?

 l'eventualità di usarle, specie se DEVE ;)  understood?
Io rispondevo alla tua frase di cui sopra. Frase con la quale non mi
sento in accordo, ergo espongo la mia posizione, lunga e volutamente
completa. Se non sei d'accordo per qualche motivo, mi piacerebbe saperlo
e ne parliamo, potresti benissimo mostrarmi un aspetto che avevo
trascurato.


 wrote:
|
| > in qualche modo cercano di porre rimedio a situazioni
estreme, tu le usi
| > quasi al posto di un IF!!!
|
| Tuttavia se effettivamente l'eccezione è molto rara, anche
per ragioni
| prestazionali potrebbe convenire fare con il try (ma qui
si entra nel
| campo "ottimizzazione", che è pelosissimo...). Oppure
anche una
| considerazione che faccio dopo potrebbe fare propendere
per un EAFP.
Si sono d'accordo!
| Ovviamente se gli altri con cui lavoro si aspettano LBYL e
io gli do
| EAFP per loro *non* sarà particolarmente chiaro (anche se
sicuramente
| più chiaro che infilare del LBYL quando uno si aspetta
EAFP).
Questo è il motivo del perchè gli abbia domandato se per
caso non fosse possibile usare
un IF piuttosto che lanciare una eccezione o gestirla.

si si tutto chiaro e sono d'accordo!