Exceptionbehandlung --> catch/throws

[Fiandus]

Hallo zusammen,

mir ist gerade etwas aufgefallen, was ich einfach nicht verstehe. Bis jetzt bin ich davon ausgegangen, dass es zwei Möglichkeiten zur Ausnahmebehandlung gibt:

1.: man packt die kritische Stelle, die eine Ausnahme auslösen kann DIREKT in einen try und catch-Block --> Ausnahmebehandlung erledigt.

2.:man schreibt an den jeweiligen Funktionskopf "throws XException", wobei dies nur ein WEITERLEITEN der Exception ist, welche später irgendwann trotzdem von einem try und catch-Block gefangen werden muss.

Jetzt habe ich aber grad gesehen, dass ich eine Exception per throws weiterleiten kann OHNE sie später per try und catch aufzufangen.

Die Klasse um die es sich handelt ist folgende (Großschreib-Document):

import javax.swing.text.AttributeSet;
import javax.swing.text.BadLocationException;
import javax.swing.text.PlainDocument;

public class FieldDocument extends PlainDocument
{
	public void insertString(int off, String s, AttributeSet a) throws BadLocationException
	{
		super.insertString(off, s.toUpperCase(), null);
	}
}

Zunächst hatte ich den super-Aufruf von insertString in try und catch gesetzt, das ergab für mich Sinn. Anschließend hab ich den try und catch-Block entfernt und das Throws an den Funktionskopf angehangen. Ich habe jetzt in der Klasse welche eine Instanz des FieldDocuments erzeugt keinen try und catch block..sprich die Exception wird nur weitergeleitet, aber nirgendwo aufgefangen..und trotzdem krieg ich keine Fehlermeldung.

Kann mir das jemand erklären bitte? Ich bin bis jetzt wie gesagt davon ausgegangen, dass "throws" nur zum weiterleiten von Exceptions da ist und dass JEDE Exception früher oder später per try-catch gefangen werden muss.

Vielen Dank!

 

[TheRealSpikee]

Hehe , nein , da hast du einfach nur einen Denkfehler. Wenn dieses THROWS nirgends gecatcht werden würde würde man das garnicht compilen können.
Viel wichtiger ist hier eigentlich die Frage : WER callt diese Methode ? Nun , das wird vom EDT aus gemacht : nämlich der KeyListener des Eingabefeldes dem dieses Document zugewiesen wurde.
Das ganze ist etwas komplizierter zu erklären als es ist wenn man es verstanden hat , aber lass dir für den Anfang so viel gesagt sein : DORT , wo insertString() gecallt wird wird diese Exception gecatcht.

 

[Fiandus]

Ah okay, ich glaube ich weiß so in etwa wie das gemeint ist. Ich werd mal ne Nacht drüber schlafen, ist eh schon spät. Vielen Dank jedenfalls schonmal 🙂

 

[bygones]

Hehe , nein , da hast du einfach nur einen Denkfehler. Wenn dieses THROWS nirgends gecatcht werden würde würde man das garnicht compilen können.

mhm

public class Foo {
  public static void main(String[] args...) throws IOException {
    throw new IOException("b lub");
  }
}

compilierbar

 

[Asgar13]

mhm

public class Foo {
  public static void main(String[] args...) throws IOException {
    throw new IOException("b lub");
  }
}

compilierbar

Dadurch leitest du die Exception an einen möglichen DAU weiter :lol:

 

[HoaX]

Dadurch leitest du die Exception an einen möglichen DAU weiter

Hä? Die landet auf der Konsole, welche meistens nicht angezeigt wird.

 

[TheRealSpikee]

mhm

public class Foo {
  public static void main(String[] args...) throws IOException {
    throw new IOException("b lub");
  }
}

compilierbar

HAHA ... darf ich lachen du Pommes ?

Wenn du main() ein throws mitgibts ... was meinst wo das landet ?

BEIM CALLER VON MAIN ... und damit irgendwo in den tiefen der VM ... es wird also auch da irgendwo gefangen ...



ey wie geil ... wenn man keine Ahnung hat einfach mal sinnlosen Mist posten und sich schlau fühlen ...

gott junge ... die mal die DOC lesen ... das ist ja beschränkt ...

 

[...ButAlive]

Das was TheRealSpike schreibt ist so auch nicht ganz richtig.

Zunächstmal unterscheidet man in Java zwischen Checked- und Unchecked-Exception (es gibt noch Errors aber die lass ich jetzt mal der einfachheithalber weg).
Der Unschied zwischen beiden ist, das Checked-Exceptions in einem catch-Block gefangen werden oder mit throws weitergeleitet werden müssen, Unchecked-Exceptions können gefangen oder weitergeleitet werden. Unchecked-Exceptions sind alle Exceptions, die von java.lang.RuntimeException abgeleitet sind, Checked Exceptions alle anderen.
Wenn eine Unckecked-Exception nirgendwo gefangen wird oder eine Checked-Exception in der main-Methode geworfen wird, dann flieg sie bis zu einer Implementierung von Thread.UncaughtExceptionHandler (Thread.UncaughtExceptionHandler (Java Platform SE 6)). Davon hat jeder Thread einen und jeder Programmcode wird in einem Thread ausgeführt. In der Standard-Implementierung wird die Exception dann auf der Konsole ausgegeben, aber man könnte auch eine Implementierung schreiben, die z.B. dem User einen Dialog anzeigt.

@Fiandus Ich hoffe ich konnte dir mit meiner Erklärung etwas helfen.

@TheRealSpikee dein Vorschlag mit dem "Wenn man keine Ahnung hat, sollte man keinen Mist posten" und "mal die Doku lesen" (Exceptions) find ich gut...

 

[TheRealSpikee]

jo ... super erklärung ... nur nicht auf meinen post eingegangen ...


ganz erlich : was meinst du denn WO der UEH für den main-thread steckt ? der spruch : "wird an eine implementierung von UEH weitergeworfen" is genial ... und du meinst wirklich das es einen unterschied macht ob checked oder unchecked wenn man main z.b. alles thrown lässt und es dann irgendwo in der VM aufgefangen wird ? ... kurz um : dein post war viel erklärung um nur eins auszudrücken : im endeffekt wird eh alles von der VM verarbeitet und spätestens DA werden auch alle THROWABLE *um auch mal die ERROR mit einzuschließen* gecatched ...


was TO wissen wollte : warum er bei PlainDocument.insertString(...) throws Exception keine try-catch braucht ... die antwort : weil es im EDT gefangen wird ...

ob wir uns jetzt hier nun über checked und unchecked exceptions unterhalten oder nicht ... da TO noch nich mal sowas simples weis wird er den rest auch nicht verstehen ...




ey ihr seit hier so banane in dem board ...

 

[Illuvatar]

ey ihr seit hier so banane in dem board ...

Das erinnert mich an den Witz mit
"Was soll das heißen, da ist *ein* Geisterfahrer auf der Autobahn? Da sind doch hunderte!"

 

[...ButAlive]

Mein Gott komm mal wieder runter, aber gut nur weil du weil du hier abgehst, heißt das noch lange nicht das du Recht hast.

Du hast nur damit Recht, dass ich nicht auf die Frage des TOs eingegangen bin, sondern auf deine Aussage, dass eine Execption immer irgendwo gefangen wird. Was ich ausdrücken wollte ist, dass du nicht unbedingt ein catch(Throwable) finden wirst, sondern, wenn eine Exception durchfliegt, ein anderer Mechanismus greift. Außerdem ist der Titel des Threads Exceptionbehandlung, da wird man doch noch auf Exceptionbehandlung tiefer eingehen dürfen.

Aber zurück zur Frage vom TO:

In deinem Beispiel wird die BadLocationException von PlainDocument einfach nur weiter geworfen, das entspricht doch genau dem was du davor beschrieben hast. Sobald du FieldDocument#insertString aufrufst musst du was mit der BadLocationException machen. Da hilft dir auch der EDT nicht, solange du eine Checked-Exception hast. Beim EDT kommen nur Unchecked-Execptions und Errors an und in aller Regel werden diese auch einfach nur weiter geworfen so dass sie dann beim UncaughtExceptionHandler an.

 

[Fiandus]

Danke euch für eure Antworten. Jetzt ist es mir klar =). Die insertString-Methode wird in meinem Quellcode ja gar nicht aufgerufen. Sie wird im EDT aufgerufen, was mit dem KeyListener des Documents zu tun hat (so in etwa).

Probehalber habe ich einfach mal in einer anderen Klasse explizit die insertString-Methode aufgerufen und dort musste ich die Exception dann auch catchen. Und sie muss gecatcht werden weils eine checked-Exception ist. Das mit den checked- und unchecked-Exceptions ist übrigens nicht neu für mich, es war mir nur entfallen 😳 Das mit dem UncaughtExceptionHandler hingegen wusste ich noch nicht.

Jedenfalls vielen Dank für eure Hilfe TheRealSpikee und ...ButAlive.

Thema wäre dann damit erledigt :toll: