Sinn eigener Exceptions

[Kiola]

Hallo,

ich frage mich gerade, was der Sinn ist eigene Exceptions zu schreiben.
Ich habe ein Programm geschrieben, welches verschiedene Exceptions abfängt wie z. B. NumberFormat, FileNotFound und IOException. Zusätzlich habe ich eine eigene Klasse FormatException geschrieben, die Formatfehler der Datei abfängt. Jede Mal, wenn z.B. in der Datei ein Zeichen an einer Stelle auftaucht, welches dort nicht auftauchen soll, wird throw new FormatException("text.."); aufgerufen.
Jedoch frage ich mich gerade, ob es nicht dasselbe ist, wie wenn ich throw new Exception("text.."); aufrufe.

Viele Grüße, Kiola

 

[Foermchen82]

Es macht sinn verschiedene Exceptions zu benutzen, da du dann in den Catch-Anweisungen auf Verschieden Fehler reagieren kannst. Wenn du allerdings meinst: "Alles was passieren kann, tue immer das selbe" Dann kannst du auch nur mit "Exception" arbeiten. Ist aber unschön

 

[Der Müde Joe]

Exceptions sollten immer so spezifisch wie nur möglich sein. Dann kann man auch gesondert darauf reagieren.
Ein falsches Format eiggegeben FormatException. Der User kann nochmals. FileCorruptedException: Da kann man dann nicht
mehr viel machen. Wenn einfach alles Exception ist, kann man nicht mehr speziell auf Ereignisse reagieren.

 

[Kiola]

aber wenn ich in dem catch-Block eh nur e.getMessage() ausgebe und sonst nichts anderes mache.. reicht es dann nicht einfach throw new Exception("text") zu machen?

 

[Der Müde Joe]

Dann stellt sich eher die Frage: Wieso eine Exception werfen, wenn sie eh nicht behandelt bzw weitergereicht wird?

 

[Marco13]

Die Antwort könnte sein: Vielleicht will sie jemand anderes behandeln oder weiterreichen. Die Frage, warum man ein pauschales "catch(Exception e){printSomething();}" macht, wäre da IMHO interessanter

 

[Kiola]

Der Benutzer soll ja mitkriegen, was er in der Datei falsch gemacht hat

 

[ice-breaker]

aber dann schreibt man ihm nicht einfach nur eine Fehlermeldung auf die Console.
frei nach dem Motto: "Da ist ein Fehler, mach mal" ?

In dem Falle, wenn ein Fehler auftritt würdest du ihm das sagen und ihn gleich zu der Stelle zurückbringen, wo er den Fehler beheben kann oder anderes.
Einfach nur eine Fehlermeldung ausgeben ist keine Fehlerbehandlung.

 

[Kiola]

ja natürlich muss man dann eine sinngemäße Fehlermeldung ausgeben, die einem dann sagt WO man was falsch gemacht hat.
Trotzdem verstehe ich dann nicht wirklich, wofür man eine eigene Exception Klasse definiert. Mit throw new Exception("..") kann man dem Benutzer ja auch genau sagen, wo sein Fehler ist und warum

 

[Foermchen82]

Exceptions dienen aber nicht nur dazu, dem User etwas mitzuteilen. Auch das System kann reagieren. Hier hilft es zu wissen, was passiert ist. Das System kann mit der Message nichts anfangen, wenn es z.b. ein Reconnect in 5 min versuchen soll bei einer NoConnectionException.

 

[Marco13]

Die Methode müßte dann aber

void method() [b]throws Exception[/b]

heißen, und jeder müßte sich um "irgendwas" kümmern, was da passieren kann. Was soll man als Begründung in den Kommentar schreiben?

...
 * @throws Exception If something goes wrong. You should better catch and ignore this.
 */

Um dem Benutzer mitzuteilen, dass etwas schief gegangen ist, könnte man ja auch

System.out.println("Ooops");
System.exit(-666);

machen

Es gibt außerdem einige Gute gründe, warum man nur RuntimeException verwenden (bzw. davon erben) sollte, und nicht Exception...

 

[Gast2]

Trotzdem verstehe ich dann nicht wirklich, wofür man eine eigene Exception Klasse definiert.

na in Plugins zum Beispiel

wenn Du eine Plugin-Methode aufrufst, kann irgendwo (in den Tiefen des Plugin-Universums) eine Exception kommen ... jetzt kann natürlich das Plugin die Exception behandeln - oder nicht ... wenn das Plugin die Exception behandelt, kann es eine neue neue Exception werfen (z.B. PluginException) oder normal weiter verfahren ... mit der PluginException kann das Plugin dem hauptprogramm Signalisieren "ich hatte ein Problem - ist jetzt aber gelöst" ... fliegt aber im Plugin eine "unerwartete" Exception (NullPointerException/Division durch 0) - wird das nicht behandelt

unterm Strich kommen die Exception im hauptprogramm an bei einer PluginException kann das Hauptprogramm den Benutzer über den Fehler informieren ... bei anderen Exception (die nicht von PluginException erben) kann das Hauptprogramm das Plugin generell blockieren

Calculon - All My Plugins - das zweite Plugin anschauen ... da habe ich es auch kurz angerissen

hand, mogel