# Hilfe bei Exceptions



## BaronHumbertvonGikkingen (20. Dez 2021)

Hallo,
ich habe derzeit ein Problem bei einer Hausaufgabe, also man sollte was in der Methode berechnen und darf auch eine Hilfsmethode erstellen.

Die Aufgabe war halt kinderleicht, aber ich habe Probleme mit den Exceptions. Ich soll eine Exception "werfen", wenn
 if(array.length > 3)  so eigentlich eine einfache Aufgabe.
Aber irgendwie klappt es nicht. Meine Exception habe ich in einer anderen Klasse, die erbt auch von Exception.

Wenn ich die Exception einbauen will, dann schreibe ich:
if (d.length > 3)
throw new "..."Exception("Falsche Anzahl);

Wenn ich das aber einbaue, dann meckert Eclipse und gibt als lösung vor : Add throws declaration.

Also meine Methode würde dann lauten

......()  throws Exception.

Dann klappt es auch, aber jetzt ein Problem, denn dadurch schlagen alle meine JUnit Tests fehl..

Wenn ich bei den Tests nachschaue, dann darf da kein throws Exception stehen, aber wie mache ich das dann?

Wenn ich in den Folien der Vorlesungen schaue, dann wird das sogar 1 zu 1 so gemacht.

Die Videos schaue ich mir nicht an, weil ich mir meistens nur die Codes anschaue und dann schreibe ich von oben nach unten ab, was im Code passiert. Für mich ist das besser zum Verständnis.


----------



## LimDul (20. Dez 2021)

Ein paar Dinge:

Es gibt zwei Arten von Exceptions:
a) Exceptions die von RunTimeException (oder einer ihrer Subklassen) erben
b) Sonstige Exceptions, die von Exception (oder einer ihrer Subklassen außer RuntimeException) erben. Diese werden auch checked Exceptions genannt.

Für die Exceptions von Typ b gilt - sobald ein throw new  XYExceptionin einer Methode drin steht, muss im Methodenkopf auch ein thows XYException definiert werden. Da es checked Exceptions sind, ist der Aufrufer verpflichtet diese entweder zu fangen und behandeln oder weiterzuwerfen.

Im Unit Test ist es normalerweise kein Problem ein throws XYException dranzuschreiben. Problematisch wird es nur, wenn die Exception geworfen wird (iund nicht im Testfall behandelt wird) - weil das signalisiert dann einen fehlgeschlagenen Testfall, weil das erwartete Ergebnis nie ist, dass die Testmethode eine Exception wirft.

Wenn man im Testfall testen will, ob eine Exception kommt, gibt es ein paar Möglichkeiten, Möglichkeit a) - die nicht so schöne


```
public void testException() {
try {
methodeDieExceptionWerfenKann();
fail("Es wurde keine Exception geworfen");
catch (XYException e) {
assertTrue(e != null);
}
}
```

Alternativ bietet JUnit auch diverse Methode zum checken, ob eine Exception geworfen wurde, bevor ich mir die Finger wund schreibe, kann man das hier besser nachlesen: https://www.baeldung.com/junit-assert-exception


Dieser Test ist unabhängig davon ob es eine Checked oder Unchecked Exception ist.

Wo genau der Fehler jetzt bei dir liegt, kann man sagen - was mir auffällt. Man deklariert nicht throws Exception sondern throws KonkreteExceptionKLasse, evtl. hilft das schon.


----------



## kneitzel (20. Dez 2021)

Bei Exceptions gibt es zwei Arten: Checked und Unchecked Exceptions. Bei Checked Exceptions ist es notwendig, dass die Methodensignatur dies vorgibt und dann muss die Exception beim Aufrufer entweder gefangen werden oder die Methode muss ebenfalls ein throws haben.
Unchecked Exceptions erben von RuntimeException und können immer geworfen werden. Da gelten diese Regeln nicht.

So, wie Du das Problem derzeit beschreibst, sollst Du wohl eine Unchecked Exception werfen, d.h. Deine Exception muss von RuntimeException erben.


----------



## BaronHumbertvonGikkingen (20. Dez 2021)

kneitzel hat gesagt.:


> Bei Exceptions gibt es zwei Arten: Checked und Unchecked Exceptions. Bei Checked Exceptions ist es notwendig, dass die Methodensignatur dies vorgibt und dann muss die Exception beim Aufrufer entweder gefangen werden oder die Methode muss ebenfalls ein throws haben.
> Unchecked Exceptions erben von RuntimeException und können immer geworfen werden. Da gelten diese Regeln nicht.
> 
> So, wie Du das Problem derzeit beschreibst, sollst Du wohl eine Unchecked Exception werfen, d.h. Deine Exception muss von RuntimeException erben.


Hat geklappt! Vielen Dank. Also die Tests habe ich jetzt bestanden.


----------

