Perché il chiamante del metodo che genera un'eccezione non deve gestire l'eccezione in questa situazione?

Question

Si consideri la seguente interfaccia:

package hf; 

public interface BadInterface 
{ 
    void meth() throws Exception; 
} 

che viene realizzato tramite le seguenti classi:

package hf; 

public class apples implements BadInterface 
{ 
    public static void main(String[] args) 
    { 
     new apples().meth(); 
    } 

    public void meth() 
    { 
     System.out.println("Ding dong meth."); 
    } 
} 

Anche se meth() è un metodo che genera un'eccezione, il chiamante del metodo meth() è non dover gestire o dichiarare l'eccezione eppure il programma funziona correttamente. Perché è così? Non viola la regola che ogni volta che chiami un metodo che genera un'eccezione, devi catturare l'eccezione o dichiarare di lanciare l'eccezione tu stesso?

Answer 1

Quando si implementa un metodo di interfaccia, è possibile dichiarare che si scaricano in meno di eccezioni rispetto a quelle elencate nell'interfaccia.

Quando si chiama new apples().meth(), si richiama meth() in un'istanza apples. Il compilatore sa che questo non getta nulla, quindi stai bene.

se aveste fatto:

BadInterface foo = new apples(); // Note: should be Apples (code style) 
foo.meth(); 

allora si avrebbe bisogno di intercettare l'eccezione dichiarato nell'interfaccia, perché il compilatore sa solo che è di fronte ad un esempio BadInterface.

Answer 2

Secondo JLS Requirements in Overriding and Hiding:

B è una classe o interfaccia, e A è una superclasse o superinterfaccia di B, e una dichiarazione di metodo m2 in sostituzioni di B o nasconde un m1 dichiarazione di metodo in A. Poi :

Per ogni tipo di eccezione verificata elencato nella clausola throws di m2, quella stessa classe di eccezione o uno dei suoi supertipi deve verificarsi nel cancellazione (§4.6) della clausola di M1 tiri; in caso contrario, si verifica un errore in fase di compilazione.

Significa che il metodo di estensione può avere solo una politica di eccezione più forte. Se ha delle restrizioni più deboli, non è possibile utilizzare tale metodo al posto di un metodo di base e rompe il concetto di override.