try und catch

[A3XX]

Hi

Ich bins wiedermal 🙂

Hab ne Frage zu try und catch.
Hab das Kapitel jetzt durchgelesen und es ist mir noch nicht alles klar:

Der Autor schreibt es gibt drei Fälle
a) Man muss eine Exception behandeln sonst gibt es einen Compilation Error
b) Man kann die Exception behandeln wenn man will
c) die Fälle, in denen das throwing von Exceptions nicht im Methoden Header geschrieben steht

Naja, irgendwie tönt das für mich exakt gleich?! Oder wo ist der Unterschied und wie gibt man das jeweils in einer Methode an? Vermutlich ist fall c der, in welchem man nur in der Methode schreibt
throw new Exception()
aber nichts im Header. (Könnte man auch hier einene eigenen Namen für die Exception verwenden?)
Aber wie unterscheiden sich Fall a und Fall b?

 

[Isaac]

Fall b und c sind eigentlich gleich.


Grundsätzlich unterscheidet man 2 Arten von Fehlern. Einmal die Fehler bei denen der Benutzer noch eine Möglichkeit hat etwas dagegen zu unternehmen und die, wo das Kind so weit in den Brunnen gefallen ist das es kaum noch eine Möglichkeit gibt das Programm an der selben Stelle vernünftig weiter zu führen.

Die Fehler bei denen man noch etwas unternehmen kann sind meist von "Exception" abgeleitet und müssen gefangen werden (der Compiler meckert wenn man es nicht tut). Beispiele sind z.b. FileNotFoundException, DataFormatException etc etc...

Fehler bei denen man nichts mehr machen kann sind meist von "RuntimeException" abgeleitet und man muss sie nicht fangen. Man bekommt keine Warning und auch keinen Error wenn man sie nicht behandelt. Beispiele sind z.b. NullpointerException, IndexOutOfBounceException.

Hier hat man zur Laufzeit kaum eine Möglichkeit zu reagieren und würde man diese Fehler immer abprüfen müssen würde das Programm nur noch aus try catch bestehen.


Was der Author mit Fall 3 meinst weiss nicht. RuntimeExceptions müssen nicht als Throw deklariert werden und selbst wenn man sie deklariert müssen sie nicht gefangen werden. Es macht also keinen Unterschied.

 

[Illuvatar]

Noch etwas genauer: Es gibt 3 Fälle:
RuntimeException extends Exception: Kein Compilerfehler, wenn die Exception nicht behandelt wird.
Error extends Throwable: Sollte nicht behandelt werden, schwerer Ausnahmefehler der VM, z.B. kein Arbeitsspeicher mehr.
Exception extends Throwable: Muss behandelt werden. Dafür gibt es 2 Möglichkeiten (die aber bei allen Throwable angewendet werden können):
1) Weiterleiten. Dazu muss throws <Throwable> an den Anfang der Methode geschrieben werden.
2) Mit try-catch(-finally) abfangen.

Auch Fehler, die mit throw geworfen werden, müssen so behandelt ewrden.

 

[A3XX]

Hi nochma

Schon viel viel klarer alles danke euch beiden.

Nun noch ne Frage:

Mit throw kann man ja Fehler selbst auslösen right? Ich verstehe einfach noch nicht ganz die Syntax. Beim Onlinebuch (Galileo) steht throw new IllegalArgumentException
dann steht aber irgendwoe auch throw (Exception) null
Was ist da der Unterschied?! Was kann man wann brauchen?

Und der Nutzen im triggern von eigenen Fehlern seh ich auch noch nicht so ganz. Hab jetzt bisschen nachgedacht und stelle mir das so vor, dass man ähnliche FEhler auf einen Nenner bringen kann:

Zum Beispiel bei einem Programm, das die Fläche eines Dreiecks berechnen soll. (Beispiel in meinem Buch) Dort darf ja glaube ich die Summe von zwei SEiten nie grösser sein als die dritte Seite.
Dieser Fehler wird ja von Java selbst nicht irgendwie Beachtung geschenkt.
Jetzt könnte ich aber ja alle falschen Eingaben, inklusive dem, mit dem throw auf den gleichen FehlerHandler schicken right?

Und darf nach throw kein Code mehr stehen?

Ach ja, gibt es irgendwo eine schöne Grafik mit all diesen Exceptions?

 

[Isaac]

Stell dir vor du schreibst eine Klasse Auto bei dem der Nutzer alle 4 Räder selbst anbringen kann bzw muss. Der nutzer instanziiert also deine Klasse Auto und bestückt 3 Räder, das 4te vergisst er. Nun versucht er die Methode Auto.fahre() aufzurufen.

Deine Methode fahre() prüft nun ob alle 4 Räder auch wirklich an den Achsen sind. Ist dies nicht der Fall wirft deine Methode einen Fehler NotAllTiresFoundException die der Benutzer behandeln muss.

try
{
    Auto.fahre()
}
catch(NotAllTiresFoundException natfe)
{
    //Check der Reifen
    //wenn Reifen fehlen, Benutzer benachrichtigen das er gefälligst alle Reifen anbauen soll
}

Das ist nun eine, zugegebenerweise aus den den Fingern gesaugte, eigene Fehlerbehandlung. Sicher kann man alle Exceptions reduzieren. Aber man will ja wissen welcher Fehler aufgetreten ist. Deshalb macht es Sinn dem Kind einen Namen zu geben.

Code nach einer Exception macht keinen Sinn. Es sei denn in der Form

if(a == null)
{
    throw new MyNullException(Buhhh something is null);
    //hier wäre code sinnlos
}
//weiter mit Code