throw

[kostonstyle]

hallo
warum schreibt man throw hinter der Methode, obwohl in der Methode aufgerufen wird?

void dangerMethod() throws StrangeException
{
if ( unexpected ) throw new StrangeException ( "oh oh" );
} // end dangerMethod

danke kostonstyle

 

[The_S]

Damit signalisiert wird, dass die Methode eine solche Fehlermeldung werfen könnte!? Falls das deine Frage nicht beantwortet, bitte noch mal genauer stellen.

 

[diggaa1984]

die Methode leitet die Exception nach oben weiter, dass heisst sie muss sich nicht selbst drum kümmern, sondern die aufrufende Methode muss dann entweder die Exception fangen, oder selbst wieder weiterleiten, sofern sinnvoll.

 

[SlaterB]

Java könnte zum Teil auch funktionieren, ohne dass 'throws StrangeException' angegeben wird,

wenn der Compiler den Zusammenhang jetzt schon findet und eine Fehlermeldung bei fehlenden throws ausgibt,
dann könnte er sich genausogut selber das 'throws StrangeException' dazudenken
und automatisch bei allen Aufrufen try/catch prüfen usw.

interessanter wirds aber noch, wenn man die Trennung von Interface und Implementierung bedenkt,
einem Interface mit 10 verschiedenen oder noch gar nicht programmierten Implementierungen sieht man nicht an, welche Exception fliegen werden,
daher ist eine feste Angabe in der Signatur erforderlich

 

[kostonstyle]

void dangerMethod() throws StrangeException
also definiere ich hier, dass Exception von dieser Methode ausgeworfen wird?
wenn ich aber in der Methode
throw new StrangeException
auslöse, dann ist die Angabe oben gar nicht nötig?

 

[SlaterB]

doch, siehe weiter oben, sonst weiß der Aufrufer nichts von der Exception
und dieses Wissen ist wichtig, um ein try/ catch aufzubauen

 

[0x7F800000]

doch, siehe weiter oben, sonst weiß der Aufrufer nichts von der Exception
und dieses Wissen ist wichtig, um ein try/ catch aufzubauen

zum einen das, und zum anderen einfach um die Programmierung zu erleichtern.
Es wäre doch übel, wenn der compiler "throws Whatever" selber dranschreiben würde... Dann könnte man ja unbeabsichtigt 10000 try-catch blöcke vergessen, und der compiler würde eine flut von allen möglichen exceptions bis zur main weiterleiten, dann bekäme man automatisch irgendwelchen mist wie

public static void main(String[] args) throws *...235 verschiedene Exceptions...*{}

generiert, das wäre doch echt nicht der sinn der sache :autsch:

 

[tfa]

zum einen das, und zum anderen einfach um die Programmierung zu erleichtern.
Es wäre doch übel, wenn der compiler "throws Whatever" selber dranschreiben würde... Dann könnte man ja unbeabsichtigt 10000 try-catch blöcke vergessen, und der compiler würde eine flut von allen möglichen exceptions bis zur main weiterleiten, dann bekäme man automatisch irgendwelchen mist wie

public static void main(String[] args) throws *...235 verschiedene Exceptions...*{}

generiert, das wäre doch echt nicht der sinn der sache :autsch:

Dieses Verhalten gibt es ja bei unchecked Exceptions (RuntimeException) schon, die im Gegensatz zu checked Exceptions nicht gefangen oder weitergeworfen werden müssen. So sinnlos ist das nicht.
Das frisst der Compiler so, ohne dass man eine Liste der Exceptions abgeben muss.

 

[0x7F800000]

Ja, natürlich, aber bei Unchecked Exceptions war das ja genau der sinn, dass sie "meistens" auf denkfehler im Programm hindeuten, und deswegen auf der Konsole landen sollten... Aber einfach alles weiterzuwerfen wäre sicher nicht im Sinne des Erfinders...

 

[maki]

Die frage ob checked Exeptions einen Sinn haben oder nicht ist schon öfters diskutiert worden, man kann ohne gut leben, unchecked Exceptions reichen

 

[0x7F800000]

Die frage ob checked Exeptions einen Sinn haben oder nicht ist schon öfters diskutiert worden, man kann ohne gut leben, unchecked Exceptions reichen

...ja, diese ewige diskussionen... kommt drauf an, womit man rechnet.

 

[tfa]

Aber einfach alles weiterzuwerfen wäre sicher nicht im Sinne des Erfinders...

Ja, leider
Das Konzept der checked Exceptions hat sich nicht bewährt, finde ich. Wenn es die nicht gäbe, wäre vieles einfacher und man müsste sich solche Fragen nicht stellen.

 

[maki]

Der Trend geht eindeutig weg von checked Exeptions

Wenn man mit einer Exception rechnet, darf man ja den try/catch Block nutzen.
Aber was nutzt eine checked Exception, die einen dazu zwingt einen try/catch Block bzw. throws zu schreiben wenn es sowieso keine sinnvolle Möglichkeit gibt mit der Exception umzugehen?

 

[tfa]

Aber was nutzt eine checked Exception, die einen dazu zwingt einen try/catch Block bzw. throws zu schreiben wenn es sowieso keine sinnvolle Möglichkeit gibt mit der Exception umzugehen?

Wenn sie nur nicht nutzen würde, aber sie schadet ja auch noch.

Gerade letzte Woche hatte ich wieder ein Beispiel für bescheuerte checked Exception:

Aus der Quartz-Library...

try {   
    int day = cal.get(Calendar.DAY_OF_WEEK);
    res = new CronTrigger(createJobName(id), JOB_GROUP, "0 0 21 ? * "+ day));
}
catch (ParseException e) {
    throw new RuntimeException("unerwarteter Fehler", e);
}

Wie sollte man diese (checked) ParseException beheben? (CronTrigger erwartet eine Unix-CronJob konforme Zeitdefinition, sonst Exception). Erstens kann sie gar nicht auftreten und zweitens läuft die Sache auf einem Server.

 

[Ark]

Das Problem ist hier weniger der Mechanismus an sich, als vielmehr die Tatsache, dass eine ParseException keine RuntimeException ist. Für meine Begriffe widerspricht sich die Java-API da selbst, denn Integer.parseInt() zum Bleistift wirft eine NumberFormatException (extends IllegalArgumentException extends RuntimeException). Genauso hätte auch eine ParseException bei Integer.parseInt() gepasst - das wäre ja schon vom Namen her logisch.

Ark

 

[kostonstyle]

Bitte gehe nicht zu tief in das Thema, zuerst muss ich das einfachere kapieren.
also, gehe wir nochmals schritt für schritt
man schreibt throws blabla damit der Compiler weiss, dass in der Methode blabla ein Exception ausgelöst wird?

 

[maki]

ParseException ist teil des Packages java.text, ausserdem ist sie älter als die IllegalArgumentException.

Selbst wenn der Name besser passen sollte, handelt es sich dabei um eine checked Exception, daher ist die IllegalArgumentException auf jedenfall zu bevorzugen

 

[tfa]

Bitte gehe nicht zu tief in das Thema, zuerst muss ich das einfachere kapieren.
also, gehe wir nochmals schritt für schritt
man schreibt throws blabla damit der Compiler weiss, dass in der Methode blabla ein Exception ausgelöst wird?

Sry, wir schweifen ab.

Also, das "throws BlaException" an der Methode bedeutet, dass die Methode eine BlaException werfen kann. Sie muss nicht unbedingt bei jedem Aufruf, nur wenn eben die entsprechende Ausnahmesituation eintritt, die die Exception nötig macht.

Durch diese Deklaration weiß der Aufrufer der Methode, dass hier diese Ausnahme auftreten könnte. Er muss sie also entweder behandeln (try-catch) oder weiterleiten. Das weiterleiten geschieht wiederum mit der throws-Klausel.

 

[Empire Phoenix]

Um nochmal auf die frage zu kommen:

thow in einer Methode aka public void bla() throws Keks{irgetwas}

Bedeutet das diese Methode evtl eine Exception des Types Keks werfen wird.
Beim verwenden dieser Methode kann man nnun mit try / catch entweder direkt das Problem abfangen.
Beispiel eingabefeld für alter enthält Buchstaben, im ctach würde man dann eine Fehler meldung im Sinne von nur Zahlen oder so erstelln.

throw new Keks();

new Keks() //Keks extends Exception
is soweit klar nehme ich an.

das throw Bedeutet jetzt das die Exeption höhergeworfen wird.

Zum Beispiel wieder unser RegestreigunsFormular mit de Alter.
Man könnte die Fehler immer weiter werfen mtihilfe von throws , theoretisch bis zur main methode (die kann auch throwen, dann beendet sich aber das Programm). Dort oben abgefangen könnten wir statdessen eine Fehlermeldung im Sinne von Regestrirung nicht Möglich, überprüfen sie ihre eingegebenen Daten ausgeben.

throw in einer Methoden deklaration ohne das eine Exceptione rzeugt wid, bedeutet also, das wir die Exception einer aufgerufenen Methode weiterreichen.

 

[kostonstyle]

also der throws sagt an, dass in dieser Methode Fehler auftreten könnte und ist auch für Fehlerquelle leichter ausfindig zu machen. Diese Methode muss in einen Try/Catch Block stehen, sonst spuckt der Compiler Fehlermeldungen aus. Stimmts?
Was ich noch nicht ganz verstehe ist, was meint ihr mit rauswerfen oder höherwerfen in einer Exception?

 

[tfa]

Entweder so:

public void meineMethode() {
    try {
         objekt.methodeDieBlaExceptionWirft();
    }
    catch(BlaException x) {
         ... //Exception behandeln
    }
}

Oder so:

public void meineMethode() throws BlaException{    
    objekt.methodeDieBlaExceptionWirft();
}

In diesem Fall muss der Aufrufer von meineMethode() eben die Exception fangen (oder wieder weiterwerfen).

 

[AmunRa]

Was ich noch nicht ganz verstehe ist, was meint ihr mit rauswerfen oder höherwerfen in einer Exception?

das bedeutet, dass der Fehler nicht in dieser Methode a) in der der Fehler auftritt behandlet wird, sonder in der Methode b) die die Methode a) aufgerufen hat

 

[kostonstyle]

heisst es also
wenn ein catch nicht für den Fehler zuständig ist, wird es weiter an andere catch "geworfen"?

 

[tfa]

Richtig. Aber zusätzlich muss noch das throws an der Methode stehen, sonst meckert der Compiler. Jedenfalls bei checked Exceptions.

 

[kostonstyle]

ok...jetzt ist es klar....
vielen dank für eure mühe leute.....