[JAVA] Chiarimento sugli override

[andbin]

Sto vedendo la questione dei metodi di override in Java. Il concetto di override, in generale, mi è chiaro. Quello che mi è un po' meno chiaro sono le restrizioni per quanto riguarda le eccezioni. Il mio libro, per le eccezioni sugli override, riporta: "Can reduce or eliminate. Must not throw new or broader checked exceptions"

Prendiamo per esempio:
import java.io.*;

class SuperClass
{
void doSomething () throws IOException { }
}

class SubClass extends SuperClass
{
....override di doSomething....
}
Questi override sono OK:
(1) void doSomething () { }
(2) void doSomething () throws FileNotFoundException { }
(3) void doSomething () throws FileNotFoundException, EOFException { }

mentre questi sono errati:
(4) void doSomething () throws Exception { }
(5) void doSomething () throws InterruptedException { }

Se ho capito bene, il perché (4) e (5) sono errati è dovuto al fatto che chi poi userà il metodo doSomething (ad esempio tramite un reference alla classe base) è solamente a conoscenza del fatto che l'eccezione "più larga" che può essere generata è la IOException. Se un override potesse lanciare una eccezione nuova o più "larga", il chiamante non saprebbe/potrebbe gestirla. Giusto?
Ditemi se ho capito! ;)

[dupa]

Sto vedendo la questione dei metodi di override in Java. Il concetto di override, in generale, mi è chiaro. Quello che mi è un po' meno chiaro sono le restrizioni per quanto riguarda le eccezioni. Il mio libro, per le eccezioni sugli override, riporta: "Can reduce or eliminate. Must not throw new or broader checked exceptions"

Prendiamo per esempio:
import java.io.*;

class SuperClass
{
void doSomething () throws IOException { }
}

class SubClass extends SuperClass
{
....override di doSomething....
}
Questi override sono OK:
(1) void doSomething () { }
(2) void doSomething () throws FileNotFoundException { }
(3) void doSomething () throws FileNotFoundException, EOFException { }

mentre questi sono errati:
(4) void doSomething () throws Exception { }
(5) void doSomething () throws InterruptedException { }

Se ho capito bene, il perché (4) e (5) sono errati è dovuto al fatto che chi poi userà il metodo doSomething (ad esempio tramite un reference alla classe base) è solamente a conoscenza del fatto che l'eccezione "più larga" che può essere generata è la IOException. Se un override potesse lanciare una eccezione nuova o più "larga", il chiamante non saprebbe/potrebbe gestirla. Giusto?
Ditemi se ho capito! ;)


Il senso è che chi chiama genericamente i metodi su SuperClass (usando quindi il polimorfismo) si dovrà gestire come catch l'eccezione IOException.

Se fai un ovverride non mandando nessuna eccezione.. OK
Se mandi IOException.. OK
Se mandi un'eccezione che estende IOException.. OK (poi il catch gestirà la gestirà come IOException)

Se mandi eccezioni diverse da IOException e che non sono sue sub-eccezioni, il catch non saprà gestirle :)

[andbin]

Se mandi eccezioni diverse da IOException e che non sono sue sub-eccezioni, il catch non saprà gestirle :)Quindi ho capito bene il concetto! Grazie.

Approfitto per chiedere una cosa: esiste da qualche parte in rete un reference con l'elenco/schema gerarchico di tutte le eccezioni dei package standard di Java??

[dupa]

Quindi ho capito bene il concetto! Grazie.

Approfitto per chiedere una cosa: esiste da qualche parte in rete un reference con l'elenco/schema gerarchico di tutte le eccezioni dei package standard di Java??

mi pare che siano direttamente nel doc/ del JDK

[kingv]

Approfitto per chiedere una cosa: esiste da qualche parte in rete un reference con l'elenco/schema gerarchico di tutte le eccezioni dei package standard di Java??


nella documentazione javadoc per ogni package è disponibile la vista ad albero, basta che prendi quella del package java.lang:
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/package-tree.html

[andbin]

nella documentazione javadoc per ogni package è disponibile la vista ad albero, basta che prendi quella del package java.lang:
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/package-tree.htmlSì, in effetti questa è una possibilità. Preferirei però un qualche documento pdf con tutte le eccezioni disposte in un modo un po' "compatto".