Paar Fragen zu Exceptions

[java__neuling]

Hallo,

ich habe ein paar Verständnisfragen zu Exceptions:

Habe hier folgende Methode:

public static int eingabeInt() throws NullPointerException{

	int ganzzahl;

	ganzzahl=Konsole.getInputInt("Bitte Ganzzahl eingeben = ");

	return ganzzahl;

}

Ich frage mich was dieser Ausdruck zu bedeuten hat:

throws NullPointerException

Mir ist schon klar, dass irgendwann mal aus irgend einen Grund eine Exeption geworfen wird aber wann wird diese dann geworgen?

Außerdem bin ich momentan der Meinung, dass das zu einer Exception immer auch ein try und catch gehört. In der gesamten Klasse bzw. in der gesamten Java-Datei exisitert aber kein Try bzw. catch.....

Kann jemand etwas Licht ins dunkle bringen? ???:L
DANKE!:toll:

 

[preachie]

Ich empfehle Dir folgenden FAQ Beitrag, der dürfte Dir die ein oder andere Frage bereits beantworten

http://www.java-forum.org/java-faq-beitraege/103949-exception.html

 

[tfa]

Mir ist schon klar, dass irgendwann mal aus irgend einen Grund eine Exeption geworfen wird aber wann wird diese dann geworgen?

Das muss man nicht unbedingt auf den ersten Blick erkennen können. In deiner Methode kann es nur sein, dass irgendwo innerhalb des getInputInt() eine solche Exception geworfen wird (ich nehme an "Konsole" ist eine Klasse). Dazu müsste man sich aber den Quelltext dieser Methode genauer ansehen.
Darüber hinaus ist NullPointerException eine unchecked Exception, d.h. es ist nicht notwendig, diese an der Methode zu deklarieren. Du könntest das throws also genauso gut weg lassen.

Außerdem bin ich momentan der Meinung, dass das zu einer Exception immer auch ein try und catch gehört. In der gesamten Klasse bzw. in der gesamten Java-Datei exisitert aber kein Try bzw. catch.....

Muss nicht unbedingt. Exceptions fängt man, wenn man igendwie auf sie reagieren kann. Wenn man das nicht tut, fliegen sie dem Aufrufen eben um die Ohren und das Programm spuckt eine Fehlermeldung aus.

 

[java__neuling]

Ich empfehle Dir folgenden FAQ Beitrag, der dürfte Dir die ein oder andere Frage bereits beantworten

http://www.java-forum.org/java-faq-beitraege/103949-exception.html

erstmal Danke für die beiden Antworten! ;-)

Ich habe mir jetzt gerade den Link vom User "preachie" angeschaut.

Da steht drin, dass die NullPointerException, eine unchecked Exception ist.
Diese müssen nicht mit Catch and Try behandelt werden oder weitergeworfen werden.

Okay, soweit so gut. Das erklärt warum innerhalb meines Codes kein Try und kein Catch auftaucht! ;-)

Was ist jetzt aber nicht verstehe ist folgendes:

Der Link "beschreibt" die NullPointerException so:

public void methodeMitRuntimeException() {
    throw new NullPointerException();    // NullPointerException ist eine RuntimeException
}

In meinen Code steht die NullPointerException aber im Methodenkopf:

public static int eingabeInt() throws NullPointerException{

und es steht kein

new

davor?

warum ist das so? Wo ist der Unterschied?

Danke und Gruß!

 

[Gast2]

throws DeineException

deutet an, dass die Methode eine DeineException werfen kann. (steht nur am Methodenkopf)

throw new DeineException()

kannst du innerhalb einer Methode aufrufen um eine DeineException von hand zu werfen. (steht nur innerhalb der Methode)

 

[preachie]

public static int eingabeInt() throws NullPointerException{

sagt aus, dass die Methode einagebInt() eine NullPointerException werfen kann. Es bedeutet nicht, dass auch bei jedem Aufruf dieser Methode eine NullPointerException geworfen wird. Es signaliert dem Entwickler, wenn er diese Methode verwenden möchte, dass diese eine Exception von diesem Typ werfen kann und er entsprechend darauf reagieren sollte/muss.

    throw new NullPointerException();

erzeugt/wirft eine (neue) NullPointerException

Beachte auch, dass es einmal

throws

heißt und beim anderen

throw

 

[java__neuling]

throws DeineException

deutet an, dass die Methode eine DeineException werfen kann. (steht nur am Methodenkopf)

throw new DeineException()

kannst du innerhalb einer Methode aufrufen um eine DeineException von hand zu werfen. (steht nur innerhalb der Methode)

erstmal wieder bestne Dank für die schnelle Hilfe!

d.h. also wenn es innerhalb der methode steht wird die exception 100% geworfen, oder?!


könnt ihr mir sagen welchen sinn es hat bei einer eingabe methode eine nullpointer exception zu werden?!

 

[Gast2]

d.h. also wenn es innerhalb der methode steht wird die exception 100% geworfen, oder?!

Wenn irgendwo [c]throw SomeException("Bad things happen")[/c] steht, wird sie auch geworfen.

könnt ihr mir sagen welchen sinn es hat bei einer eingabe methode eine nullpointer exception zu werden?!

Wenig. Ich würde eher eine IllegalArguementException werfen wenn z.B. der Programmierer [c]null[/c] übergibt obwohl er das nicht darf. Eigentlich finde ich sollte man NullPointerExceptions gar nicht werfen. Der Grund für einen NPE ist in der Regel ein Programmierfehler der durch Testen und sorgfältiges Design vermieden werden kann.

 

[java__neuling]

okay danke!

verstehe!

Mittlerweile hat sich ein weiteres problem ergeben..... aber wir nähren uns langsam dem ende.... ;-)

Ich habe folgende Mehtide geschrieben

	public void setRadius(double r){

	if(r<0)
	{
		throw new IllegalModificationException("Fehler, der Kreisradius darf nicht negativ sein!");
	}
	else
	{
		radius = r;
	}

	}

Wenn ich kompeliere bekomme ich folgende Fehlermeldung:


test.java:104: unreported exception gdfp.geomfetrie.modefll4.IllegalModifi
cationException; must be caught or declared to be thrown
throw new IllegalModificationException("Fehler!");
^
1 error

geht mir langsam aufem sack...was mache ich den schon wieder falsch.
das catch-try dazu befindet sich in einer anderen klasse.....eben in der klasse in der die methode auch aufgerufen wird.....

DANKE!!!!

 

[Gast2]

Ich wäre zwar immer noch für eine IllegalArgumentException aber eine IllegalModificationException musst du "ankündigen".

public void setRadius(double r) throws IllegalModificationException{
...
}

 

[java__neuling]

erstmal wieder bestne Dank für die schnelle Hilfe!

d.h. also wenn es innerhalb der methode steht wird die exception 100% geworfen, oder?!


könnt ihr mir sagen welchen sinn es hat bei einer eingabe methode eine nullpointer exception zu werden?!

@fassy

DANKE hat funktioniert!

naja d.h. aber man sollte immer oben im kopf die exception datei reinschreiben und innerhalb de rmethode.

eine exception die nur innerhalb der methode steht kann ja anscheinend nie geworfen werden, oder?!

 

[Michael...]

naja d.h. aber man sollte immer oben im kopf die exception datei reinschreiben und innerhalb de rmethode.

eine exception die nur innerhalb der methode steht kann ja anscheinend nie geworfen werden, oder?!

Nicht ganz, wenn innerhalb einer Methode eine Exception geworfen werden kann, muss das mittels

throws ...

am Methodenkopf "veröffentlicht" werden.

Oder mit anderen Worten: die Exception fliegt innerhalb der Methode, durch das

throws...

zeigst Du allen die diese Methode verwnden wollen: Achtung, hier könnte was schief gehen.

 

[java__neuling]

super mal wieder BESTEN DANKE und gute NACHT! ;-)

 

[Gast2]

Nicht ganz, wenn innerhalb einer Methode eine Exception geworfen werden kann, muss das mittels

throws ...

am Methodenkopf "veröffentlicht" werden.

Oder mit anderen Worten: die Exception fliegt innerhalb der Methode, durch das

throws...

zeigst Du allen die diese Methode verwnden wollen: Achtung, hier könnte was schief gehen.

Nebenbei weiß ich jetzt erst jetzt nach 3 Monate C# wie wertvoll das ist...

Es ist echt uncool gegen eine API zu programmieren wo einem alle Nase lang Exceptions um die Ohren fliegen können aber der Compiler einen nicht drauf hinweist. Das erhöht den Entwicklungs und Testaufwand um einiges. Mag sein das es besser wird wenn ich die .NET API bessser kenne - aber das kann es ja eigenltich nicht sein.

 

[tfa]

Es ist echt uncool gegen eine API zu programmieren wo einem alle Nase lang Exceptions um die Ohren fliegen können aber der Compiler einen nicht drauf hinweist.

Im Grunde genommen ist es genau umgekehrt. APIs mit checked Exceptions sind fatal. In C# machen die das schon richtig (wie in allen anderen modernen OO-Sprachen, außer Java). Diese Diskussion hatten wir vor einiger Zeit erst. Such mal im Forum.

Das erhöht den Entwicklungs und Testaufwand um einiges.

Das ist nämlich das "Problem". Man muss testen. Das kann dir der Compiler nicht abnehmen.

 

[Gast2]

Erm....

Angenommen ich habe zwei Methoden:

public boolean connect() throws SQLException{
  ... do some stuff...
  throw new SQLException("Fatal error in connection");
}

und

public bool connect(){
   ... do some stuff ...
   throw new Exception("Fatal error in connection");
}

Wenn ich gegen die API im ersten Fall programmiere weis ich direkt das etwas schlimmes passieren könnte und werde drauf hingewiesen auf diese Ausnahme zu reagieren. Im zweiten Fall kann ich erstmal so vor mich hinprödeln, alles läuft in meinen Project. Sollte jetzt ein Problem beim connect() auftreten blubbert mir eine nicht gefangene Excpetion den ganzen stack hoch.

Also muss ich als Entwickler wissen: "Oh, bei connect() könnte es sein das ich die connection nicht aufbauen kann, also muss ich eine Ausnahmebehandlung hinzufügen."

Darauf werde ich bei Java direkt hingewiesen. Ich sehe da eigentlich nur Vorteile drin, keine Nachteile. Das einem das nicht das Tsten abnimmt ist klar. Aber es vereinfacht das Programmieren meiner Meinung nach.

 

[maki]

Also muss ich als Entwickler wissen: "Oh, bei connect() könnte es sein das ich die connection nicht aufbauen kann, also muss ich eine Ausnahmebehandlung hinzufügen."

Das musst du doch sowieso.

Das Problem ist, dass es eben immer mehr Exceptions zur Laufzeit geben kann, als zur Compilezeit bekannt sind.
Man nehme zB. die NPE, IllegalArguemntException, etc. pp.

Ich sehe da eigentlich nur Vorteile drin, keine Nachteile.

"Abstraction Lekage" wäre zB. ein riesen Nachteil, d.h. dass checked Exceptions die Kapselung brechen, zu sehen zB. in RMI mit RemoteExceptions.
Ein anderer bekannter Nachteil ist, dass man manchmal eben gar nicht auf Exception reagieren kann, aber dazu gezwungen wird, oder dass eien Exception eben nie auftreten kann, aber die deklariete throws BlaBlaERsception einen dazu zwingt, einen leeren Catch Block zu schreiben, zB.

        try {
            String hostname = InetAddress.getLocalHost().getHostName();
        } catch (final UnknownHostException ignore) {
            // impossible to get here, checked exceptions force the use of try/catch
        }

Davon gibt es noch mehr Beispiele in Java...

Alles in allem überwiegen die Nachteile der checked Exceptions gegen ein paar Vorteile, sehe das wie tfa.