Warum ist Würfe Teil der Methodensignatur

Question

Warum ist eine Methode auf eine Methode Teil ihrer Signatur. Es scheint seltsam, es einzubeziehen. Hier ist ein Beispiel, wo es im Weg ist.

Wenn jemand diese Methode von außen sieht, könnte es versuchen, es zu verwenden, ohne zu wissen, dass es nicht unterstützt wird. Sie würden es nur lernen, wenn sie versuchten, den Code auszuführen.

Wenn sie jedoch so etwas tun könnten, würden sie wissen, dass die Methode nicht unterstützt wird und wenn UnsupportedOperationException RuntimeException nicht verlängert, erhalten sie einen Kompilierungsfehler. EDIT1: Aber das ist nicht möglich, weil Würfe Teil der Signatur ist, so Override wird nicht funktionieren.

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

Diese Frage betrifft Javas Design, damit ich weiß, dass es schwierig sein könnte, ohne eine der Leute zu beantworten, die daran arbeiten Tropfen durch und beantworten, aber ich hatte gehofft, dass vielleicht diese Frage an sie aufgefordert wurde, bevor oder dass es einen offensichtlichen Grund dafür gibt, warum es so erklärt werden kann.

Answer 1

Der throws Teil zeigt nicht an, dass die Methode erforderlich ist, um die erwähnte (n) Ausnahme (n) zu werfen, nicht einmal an bestimmten Stellen. Es sagt nur, dass die Funktion dies tun darf.

Einschließlich throws UnsupportedOperationException bedeutet folglich nicht, dass die Methode nicht unterstützt wird. Neben der UnsupportedOperationException ist eine RuntimeException so ein Verfahren throw dass sowieso.

Jetzt aus dem Grund, den man in der Signatur der Methode erfordern würde, läuft es auf die Fähigkeit hinaus, Ausnahmen überhaupt überprüft zu haben. Damit der Compiler entscheiden kann, ob eine Methode nur die angegebenen Ausnahmen auslösen kann, muss sie in der Lage sein zu entscheiden, dass die aufgerufenen Methoden keine nicht abgefangenen Ausnahmen auslösen können.

Dies bedeutet zum Beispiel, dass das Überschreiben einer Methode bedeutet, dass Sie keine Ausnahmen hinzufügen können, die ausgelöst werden könnten. Andernfalls würden Sie die Möglichkeit zu überprüfen, dass eine Methode, die diese Methode aufruft, nichts anderes als angegeben werfen kann . Andersherum wäre möglich (aber ich bin mir nicht sicher, ob Java das unterstützt), eine Methode überschreibend, die mit einer werfen kann, die nicht werfen kann.

So zum Beispiel:

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

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

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

Jetzt frob angegeben, um möglicherweise throw nur ExceptionA, aber this.fubar in nannte es würde die Möglichkeit eröffnen, dass etwas anderes geworfen wird, aber fubar definiert ist möglicherweise nur throwExceptionA. Deshalb ist die D.fubar eine ungültige Überschreibung, da dies die Möglichkeit eröffnen würde, dass this.fubar tatsächlich ExceptionB wirft und der Compiler wäre nicht in der Lage zu garantieren, dass frobExceptionB nicht wirft.

Answer 2

Java verfügt über zwei verschiedene Arten von Ausnahmen: checked Ausnahmen und unchecked Ausnahmen.

Nicht markierte Ausnahmen sind Unterklassen von RuntimeException und Sie müssen keine throws-Deklaration hinzufügen.Alle anderen Ausnahmen müssen im Methodenrumpf entweder mit einer try/catch-Anweisung oder mit einer throws-Deklaration behandelt werden.

Beispiel für ungeprüfte Ausnahmen: IllegalArgumentException das manchmal verwendet wird, um zu benachrichtigen, dass eine Methode mit ungültigen Argumenten aufgerufen wurde. Keine Würfe benötigt.

Beispiel für geprüfte Ausnahmen: IOException, die einige Methoden aus dem Paket java.io auslösen könnten. Verwenden Sie entweder try/catch oder add throws IOException zur Methodendeklaration und delegieren Sie die Ausnahmebehandlung an den Methodenaufrufer.