Dave94 ha scritto:
se avesse dovuto avere senso doveva stare Exception come ultimo catch in quanto il più generale di tutti gli altri Exception ?
Sì, la questione è quella. L'ordine dei catch è significativo SE ci sono due o più eccezioni da gestire che sono in relazione di ereditarietà. Una eccezione più specifica DEVE essere catchata prima di una meno specifica (più generica).
Quindi prima il catch di MyExc3 (più specifica) poi il catch di Exception (più generica).
Se due o più eccezioni sono completamente slegate, l'ordine non conta (es. IOException e SQLException, entrambe derivano da Exception ma tra di loro
non sono in relazione quindi puoi catturare prima una o l'altra, a scelta).
P.S. la dispensa Lezione15_draft.pdf accenna solo in parte questa questione a pagina 7.
Dave94 ha scritto:
cioè è errore se sta messo lì perché non fa nulla o perché in linea gerarchica non ha senso perché Exc2 non estende Exc3 (?)
No, non conta il fatto che non contiene codice, né la ereditarietà.
Molto più semplice: guarda bene il try, c'è qualcosa lì dentro che
potrebbe lanciare MyExc2?? Risposta ovvia: no.
Il compilatore SA (lo scopre) che non è possibile che il try lanci MyExc2. Se fosse possibile lanciarla, allora ci dovrebbe essere o un throw fisso di MyExc2 oppure un metodo che dichiara MyExc2 (perché essendo MyExc2 "checked" il metodo sarebbe obbligato a dichiararla).
Per il compilatore è un errore mettere un catch di una eccezione checked se poi il try NON la può lanciare. Il codice nel catch sarebbe un
unreachable code, non raggiungibile, non verrebbe mai eseguito. E appunto è un errore per le regole di Java.
Anche java.lang.Exception è tecnicamente "checked" ma fa anche da base per RuntimeException ("unchecked"), quindi è esentata dal discorso appena fatto (cioè PUOI fare un catch di Exception anche se poi nel try NON c'è nulla che possa lanciare qualcosa che è-un Exception).