Newsgroup: it.comp.java
Titolo: Runtime/Compiletime

Ciao a tutti, 2 domande correlate:
1) Esiste un modo o delle regole da seguire per determinare a priori cosa
nel codice sorgente verrà verificato a runtime e cosa verrà verificato a
compiletime?
2) Come si distingue quali eccezioni vengono verificate a runtime e quali a
compiletime?
Grazie mille.

quali a compiletime?
Se per "verificati" intendi il fatto di dover interecettare l'eccezione,
(eccezioni "checked"), solo le Exception (e discendenti da :) devono
essere esplicitamente interecettate. Le altre possibilita' sono Throwable,
RuntimeException o Error. 
-- 
God is Real, unless declared Integer.
ObjectZone - 
http://space.tin.it/computer/csadun

runtime e quali a compiletime?
Mi sembra che tutte le eccezzioni siao generate a runtime, ma che a compile
time si verifichino i potenziali rischi: se ad esempio non si inizializza
una variabile il compilatore ti avvisa.
Ciao.
Ale

 RuntimeException o Error. 
Ciao Cristiano, io non sono completamente daccordo: le checked exception 
sono le sottoclassi di IOException.
Per Elena invece aggiungo che le RuntimeException non è richiesto 
intercettarle perchè rappresentano errori di programmazione e che quindi 
vanno fatte 'saltar fuori' durante la fase di test ed eliminate 
correggendo il codice.
ciao
Marco

Alessandro Campi wrote:

Si, infatti l'esempio che fai non è una eccezione (non è una sottoclasse 
di Excpetion) ma più semplicemente un errore del compilatore
ciao
Marco

Grazie a tutti!! :-)

sono le sottoclassi di IOException.
Uh? 
http://java.sun.com/docs/books/jls/second_edition/html/exceptions.doc.html#44121
Del resto, che senso avrebbe dire che "solo" le IO sono "checked" (in inglese,
intendo :)?


 intendo :)?
Ha il senso che le checked sono quelle che il comp ti obbliga a 
controllare perchč il tuo programma (formalmente corretto) potrebbe 
fallire per le condizioni in cui si trova ad operare (contesto 
esecutivo) non perchč sia 'sbagliato', queste condizioni sono definite 
da tutti i possibili casi in cui si puň fare I/O e quindi descritti 
dalle IOExcpetion; come dicevo ad Elena, le altre, RuntimeExcpetion, 
descrivono piů degli errori di programmazione che NON dovrebbero essere 
'catchate' ma lasciate libere di risalire fino al main per essere viste 
dal programmatore/beta tester, segnalate e corrette (correggendo il 
codice, non usando try/catch)
Sei daccordo?
ciao
Marco

codice, non usando try/catch)
La domanda era retorica. :) Volevo evidenziare come "checked" si
riferisse al fatto che appunto devi trattarle esplicitamente nel codice,
con una catch o facendone il rethrow, e non al fatto che siano di I/O,
che e' solo un caso particolare di eccezione checked.



Questo e' _errato_: qualunque eccezione che estenda Exception (e che non estende
RuntimeException) e' una checked exception. Questo si allarga a tutte le eccezioni che
definisci tu nel tuo programma, per non parlare poi di tutte quelle eccezioni che fanno
parte del linguaggio (1.1) e che tu trascuri di citare:
java.awt.AWTException
java.awt.datatransfer.UnsupportedFlavorException
java.beans.IntrospectionException
java.beans.PropertyVetoException
java.lang.ClassNotFoundException
java.lang.CloneNotSupportedException
java.lang.IllegalAccessException
java.lang.InstantiationException
java.lang.InterruptedException
java.lang.NoSuchFieldException
java.lang.NoSuchMethodException
java.lang.reflect.InvocationTargetException
java.security.DigestException
java.security.KeyException
java.security.NoSuchAlgorithmException
java.security.NoSuchProviderException
java.security.SignatureException
java.security.acl.AclNotFoundException
java.security.acl.LastOwnerException
java.security.acl.NotOwnerException
java.sql.DataTruncation 
java.sql.SQLException
java.sql.SQLWarning 
java.text.ParseException
+java.util.TooManyListenersException
java.util.zip.DataFormatException
E senza citare j2EE!
Convinto?
Ciao,
    Bruno.
|
| Bruno Bossola
| A Java Software Engineer :-)
|

 parte del linguaggio (1.1) e che tu trascuri di citare:
Scusatemi ma ieri avevo il cervello un po' in vacanza. Il problema è 
nato dalle frase di Cristiano riguardo il fatto che tutto ciò che stava 
sotto Exception era checked e dalla mia immagine mentale nella quale, 
chissà perchè, Exception era divisa _solo_ in due grossi filoni (Runtime 
ed IOException), ripeto la mia materia grigia dev'essersi presa ferie 
senza avvertirmi e così me ne sono venuto fuori con una precisazione in 
origine corretta ma che poi è degenerata in una fesseria...
Sorry...
Marco

Hey, gli NG servono a questo, scusa se sono stato un po' pignolo ma avevi proprio scoperto
il fianco :-D E'importante non dare info sbagliate ai neofiti.


Thanks!!