Perché viene lanciata una parte della firma del metodo

Question

Perché si getta su un metodo parte della sua firma. Sembra strano includerlo. Ecco un esempio in cui è nel modo.

@Overide 
public void foo() { 
    throw new UnsupportedOperationException(); 
} 

Se qualcuno da cui vedere questo metodo dall'esterno potrebbe provare a utilizzarlo senza sapere che non è supportato. Lo imparerebbero solo cercando di eseguire il codice.

Tuttavia, se fossero in grado di fare qualcosa del genere, lo saprebbero osservando il metodo che non è supportato e se UnsupportedOperationException non sta estendendo RuntimeException otterrebbero un errore di compilazione. EDIT1: Ma questo non è possibile perché i lanci sono parte della firma, quindi l'override non funzionerà.

@Overide 
public void foo() throws UnsupportedOperationException { 
    throw new UnsupportedOperationException(); 
} 

Questa domanda riguarda il design Javas quindi so che potrebbe essere difficile rispondere senza una delle persone che lavorano su di esso scende di e rispondono, ma speravo che forse questa domanda è stato chiesto a loro prima o che potrebbe esserci una ragione ovvia per averlo in questo modo per spiegare il perché.

Answer 1

La parte throws non indica che il metodo è richiesto per generare l'eccezione o le eccezioni indicate, nemmeno in particolari ocations. Dice solo che la funzione è autorizzata a farlo.

Includendo throws UnsupportedOperationException non significa che il metodo non sia supportato. Inoltre lo UnsupportedOperationException è un RuntimeException quindi un metodo può essere lo throw.

Ora, per la ragione che uno lo richiede nella firma del metodo, si riduce alla possibilità di controllare le eccezioni. Affinché il compilatore possa decidere se un metodo può solo lanciare le eccezioni specificate, deve essere in grado di decidere che i metodi che chiama non possono generare eccezioni non rilevate.

Ciò significa, ad esempio, che sovrascrivere un metodo significa che non è possibile aggiungere eccezioni che potrebbero essere generate, altrimenti si interromperà la possibilità di verificare che un metodo che chiama quel metodo non possa lanciare altro che ha specificato . Il contrario potrebbe essere possibile (ma non sono sicuro che Java lo supporti), ignorando un metodo che potrebbe lanciare con uno che non può essere lanciato.

Così, per esempio:

class B { 
    int fubar(int) throws ExceptionA { 
    } 

    int frob(int) throws ExceptionA { 
     return fubar(int); 
    } 
} 

class D extends B { 
    int fubar(int) throws ExceptionB { 
    } 
} 

Ora frob è specificato possibilmente throw solo ExceptionA, ma nel chiedere this.fubar sarebbe aperta la possibilità che qualcosa d'altro è gettato, ma fubar è definito possibilmente solo throwExceptionA. Ecco perché lo D.fubar è un override non valido poiché ciò aprirebbe la possibilità che venga effettivamente generato il ExceptionB e che il compilatore non sia in grado di garantire chenon crei ExceptionB.

Answer 2

Java ha due diversi tipi di eccezioni: checked Eccezioni e unchecked eccezioni.

Le eccezioni non selezionate sono sottoclassi di RuntimeException e non è necessario aggiungere una dichiarazione di proiezione.Tutte le altre eccezioni devono essere gestite nel corpo del metodo, con un'istruzione try/catch o con una dichiarazione di lanci.

Esempio di eccezioni non controllate: IllegalArgumentException che viene talvolta utilizzato per la notifica, che è stato chiamato un metodo con argomenti non validi. Non servono tiri.

Esempio di eccezioni controllate: IOException che alcuni metodi dal pacchetto java.io potrebbero generare. O utilizzare un try/catch o aggiungere lanci IOException alla dichiarazione del metodo e delegare la gestione delle eccezioni al chiamante del metodo.