WTF dichiarazione di un metodo con throws Exception

[xnavigator]

ragazzi non capisco cosa serva scrivere un metodo seguito da un throws

class FckOff {
    private static final int a = 1;
    public void drinkCoffee(CoffeeCup cup) throws Exception {
       // CIAO!
    }
     
}

illuminatemi



forse vorrà dire che quel metodo può solo generare dannate Eccezioni del tipo Excpetion?

[andbin]

Originariamente inviato da xnavigator
ragazzi non capisco cosa serva scrivere un metodo seguito da un throws

forse vorrà dire che quel metodo può solo generare dannate Eccezioni del tipo Excpetion?

Il throws serve per dichiarare che un metodo può lanciare quella/e eccezione/i dichiarate. Ma ha senso principalmente per le eccezioni "checked", perché il compilatore controlla che il chiamante davvero le prenda in considerazione (in un modo o nell'altro, cioè catch oppure dichiararle a sua volta con throws per farle "uscire").

Un metodo comunque, in ogni caso, può sempre lanciare eccezioni "unchecked". Che puoi anche dichiararle con throws, tecnicamente, ma tanto essendo unchecked il compilatore non fa il controllo rigoroso come per le checked.

[xnavigator]

Originariamente inviato da andbin
Il throws serve per dichiarare che un metodo può lanciare quella/e eccezione/i dichiarate. Ma ha senso principalmente per le eccezioni "checked", perché il compilatore controlla che il chiamante davvero le prenda in considerazione (in un modo o nell'altro, cioè catch oppure dichiararle a sua volta con throws per farle "uscire").

quindi anche se ho un metodo definito come throws Exception
nel metodo posso fare un throw new MyException??


quel throws Exceptino del metodo specifica solo che all'esterno ci deve essere un catch per forza???

[andbin]

Originariamente inviato da xnavigator
quindi anche se ho un metodo definito come throws Exception
nel metodo posso fare un throw new MyException??

Sì. Ma sia che MyException estenda Exception (checked) che RuntimeException (unchecked).

Originariamente inviato da xnavigator
quel throws Exceptino del metodo specifica solo che all'esterno ci deve essere un catch per forza???

Non necessariamente un catch. Exception è checked, quindi il compilatore controlla che il chiamante (chi invocherà drinkCoffee) prenderà in considerazione come minimo a livello generale Exception.
Ma il "prendere in considerazione" vuol dire catturare con catch o dichiarare con throws che il chiamante può lanciare la eccezione di fuori.
Insomma il chiamante non può ignorarla, chi scrive il codice del chiamante deve fare qualcosa, catturarla o farla uscire a sua volta (e la questione si ripeterà sul ulteriore chiamante).

[xnavigator]

ma checked significa che deve esserci per forza un catch ?

[andbin]

Originariamente inviato da xnavigator
ma checked significa che deve esserci per forza un catch ?

No, che il chiamante prenda in considerazione la eccezione checked!!!

E ripeto, "prendere in considerazione" si intende: a) la catturo oppure b) la faccio "uscire" più "sopra" (e il chiamante del chiamante dovrà porsi la stessa questione).

[xnavigator]

Originariamente inviato da andbin
No, che il chiamante prenda in considerazione la eccezione checked!!!

E ripeto, "prendere in considerazione" si intende: a) la catturo oppure b) la faccio "uscire" più "sopra" (e il chiamante del chiamante dovrà porsi la stessa questione).

prenda in considerazione intedevo questi 2 punti.


ma a questo punto non capisco l'utilità di scrivere nella dichirazione del metodo throws Exception se Exception è già checked.

[andbin]

Originariamente inviato da xnavigator
ma a questo punto non capisco l'utilità di scrivere nella dichirazione del metodo throws Exception se Exception è già checked.

Pensa: se non ci fosse il throws che fa da "bandierina" alzata per indicare quali eccezioni può lanciare un metodo ..... il compilatore come farebbe a sapere quali eccezioni un metodo lancia??? Va a scansionare tutto il bytecode del metodo cercando di capire il "flusso" del codice e guardando cosa lancia in ogni punto del metodo??? Ma noooo!

Semplicemente throws è la formalità che consente al compilatore di sapere quali eccezioni può lanciare un metodo. E se tra queste ci sono eccezioni checked, controlla che il chiamante del metodo le prenda in considerazione.

[xnavigator]

Originariamente inviato da andbin
Semplicemente throws è la formalità che consente al compilatore di sapere quali eccezioni può lanciare un metodo. E se tra queste ci sono eccezioni checked, controlla che il chiamante del metodo le prenda in considerazione.

ho capito. ma a questo punto non sarebbe più logico che se uno mette la throws Exception allora in quel metodo io posso solo lanciare solo eccezioni di quell'oggetto Exception?

perchè se io metto un'altro tipo di eccezione checked, che non ho scritto nel throws, comunque il compiltare a quel punto deve andare a leggere tutto il bytecode...

[andbin]

Originariamente inviato da xnavigator
ho capito. ma a questo punto non sarebbe più logico che se uno mette la throws Exception allora in quel metodo io posso solo lanciare solo eccezioni di quell'oggetto Exception?

perchè se io metto un'altro tipo di eccezione checked, che non ho scritto nel throws, comunque il compiltare a quel punto deve andare a leggere tutto il bytecode...

No, se dichiari throws Exception il metodo può lanciare qualunque eccezione che è-un java.lang.Exception .... IOException, ClassNotFoundException, InterruptedException per dirne 3 checked.

Se fosse solo throws IOException allora può lanciare IOException, SocketException (perché sottoclasse di IOException) e altre ... ma NON ClassNotFoundException o InterruptedException perché non sono in relazione di "ereditarietà" con IOException.