IllegalArgumentException oder Exception werfen?

[maximilius]

Ich habe gelernt, dass Klassen selbst überprüfen sollen, ob sie ihre Nachrichten ausführen, oder nicht.
Ich habe hier eine Beispielklasse geschrieben, die einen Temperaturwert kapselt.

public class Temperatur {
	private float celsius;

	/**
	 * Erzeugt ein neues Temperatur Objekt und setzt die Temperatur in °C
	 * @param celsius Der Wert der Temperatur.
	 * @throws IllegalArgumentException Wenn der Wert der Temperatur physikalisch nicht möglich ist.
	 */
	public Temperatur(float celsius) throws IllegalArgumentException {
		setValue(celsius);
	}
	
	/**
	 * Setzt die Temperatur in °C
	 * @param celsius Der neue Wert der Temperatur.
	 * @throws IllegalArgumentException Wenn der neue Wert der Temperatur physikalisch nicht möglich ist.
	 */
	public void setValue(float celsius) throws IllegalArgumentException {
		if (celsius < -273.15) {
			throw new IllegalArgumentException("Es existiert keine Temperatur unter -273.15 °C!");
		}
		this.celsius = celsius;
	}
	
	/**
	 * Gibt die Temperatur in °C zurück.
	 */
	public float getValue() {
		return celsius;
	}
}

Wenn man versucht, den Temperaturwert unter 0K zu setzen, wird eine IllegalArumentException geworfen. IllegalArgumentException erbt von RuntimeException und muss daher nicht mittels try-catch abgefangen werden.

Nun interessiert mich eure Meinung:
Sollte ich an der Stelle lieber eine Exception werfen, statt einer IllegalArgumentException, damit Programmierer, die die Temperaturklasse instanziieren, gezwungen sind, eine Fehlerbehandlung zu bauen, damit ihr Programm nicht abrauscht?

lg Stephan

 

[tfa]

Wie du es gemacht hast, ist es völlig korrekt. RuntimeExceptions deuten (immer) auf Programmierfehler hin, und es ist eben ein Fehler, den Temperatur-Konstruktor mit weniger als -273.15°C aufzurufen. Der Programmierer könnte den Wert ja vorher einfach prüfen.

 

[Gast]

Ich würde mir eher ne eigene Exception schreiben die von IllegalArgumentException erbt.
Wir sind die Standard-Exceptions nicht präzise genug.

 

[maki]

Ich würde mir eher ne eigene Exception schreiben die von IllegalArgumentException erbt.
Wir sind die Standard-Exceptions nicht präzise genug.

Einer der größeren Fehler imho ist zuviele eigene Exceptions zu schreiben (am besten noch nicht mal ordentlich Dokumentiert), ein falscher Parameter lässt sich am besten mit einer IllegalArgumentException beschreiben.

 

[Marco13]

	 * @throws IllegalArgumentException Wenn der Wert der Temperatur physikalisch nicht möglich ist.

ändern in

	 * @throws IllegalArgumentException Wenn der Wert der Temperatur kleiner als -273.15°C ist

:wink:

 

[maximilius]

@tfa:

Ich möchte dem Programmierer gerne die Arbeit abnehmen, den Wert zu prüfen. (Wiederverwendung von Code)
Er könnte die Klasse beispielsweise folgendermaßen einsetzen:

// ...
	public Temperatur benutzerGibtTemperaturEin() {
		Temperatur temperatur = null;
		float eingabe;
		do {
			// eingabe wird mit Benutzereingabe gefüttert
			try {
				temperatur = new Temperatur(eingabe);
			} catch (IllegalArgumentException e) {
				// Warnhinweis für Benutzer ausgeben, dass er eine Temperatur unter 0 K eingegeben hat.
			}
		} while (temperatur == null);
		return temperatur;
	}
	//...

@Marco13:
Du hast vollkommen Recht. Das ist viel sprechender.

lg Stephan

 

[Janus]

@param celsius Der neue Wert der Temperatur, -273.15f <= celsius <= Float.MAX_VALUE
@throws IllegalArgumentException Bei ungültigen Parametern.

 

[tfa]

Wenn schon, dann richtig:

@param celsius Der neue Wert der Temperatur, -273.15f <= celsius <=  1.41679e+32f
@throws IllegalArgumentException Bei ungültigen Parametern.

 

[Janus]

mein beispiel ist richtiger
wenn in irgendeiner java version der wertebereich von float verändert wird, stimmt meine aussage immer noch. deine aber nicht.

 

[tfa]

Der Wert ist auch nicht Float.MAX_VALUE, sondern die physikalisch maximal mögliche Temperatur (müsste natürlich im Setter auch getestet werden).

 

[JPKI]

@maximilius: In deinem Code muss die Schleifenbedingung doch == null sein...

 

[Janus]

Der Wert ist auch nicht Float.MAX_VALUE, sondern die physikalisch maximal mögliche Temperatur (müsste natürlich im Setter auch getestet werden).

wird es aber nicht, und deshalb ist der größte wert, den float annehmen kann, das limit.

 

[maximilius]

Ich würde gerne zur Ausgangsfrage zurück kehren:
Wir haben festgestellt, dass IllegalArgumentException das treffendste Throwable für das Codebeispiel ist.

IllegalArgumentException muss aber nicht mittels Try-Catch Block abgefangen werden.
Nun die Überlegung: Lieber doch ein Throwable nehmen, welches abgefangen werden muss, damit der Programmierer, der die Klasse einsetzen möchte quasi einen Wink mit dem Zaunpfahl bekommt?

Was denkt ihr?

@JPKI:
Stimmt, habe es editiert.

lg Stephan

 

[maki]

checked vs. unchecked Exception, die Diskussion ist nicht neu.

Mit der checked Exception zwingt man den nutzer der Klasse/Methode, immer einen try/catch Block bzw. eine throws klausel zu schreiben, geht einem ganz schön auf den Sack, wenn man weiss dass es nicht vorkommt.

Mit einer unchecked Exception (zB. IllegalArgumentException) kann der Nutzer entscheiden, wie er damit umgeht.

Letzteres ist fast immer die bessere Wahl.

 

[maximilius]

@maki
Die Begrifflichkeit „checked Exception“ war mir nicht bekannt.
Habe danach mal im Forum gesucht und mir ein paar Beiträge durchgelesen.

In diesem Beitrag fand ich dann Folgendes:

(...)
Generell gilt: CheckedException wirklich nur dann werfen, wenn der Fehler auch durch saubere Programmierung nicht verhindert werden kann. Sonst nur RuntimeExceptions!
(...)

Ich sehe ein, dass man nicht für jede Zeile Code einen Try-Catch Block schreiben kann.
Wenn ich im Temperatur Beispiel die IllegalArgumentException verwende, kann die Klasse in Anwendungen, in der es keine Benutzereingabe der Temperatur gibt, ohne Try-Catch Block verwendet werden und in Anwendungen, wo es eine Benutzereingabe gibt, als Fehlerbehandlung mit Try-Catch Block eingesetzt werden.

lg Stephan

 

[maki]

Josh Bloch hat sich (unter anderem) darüber ausgelassen in Effective Java, gutes Buch, bald kommt die second edition.

 

[Janus]

Ich sehe ein, dass man nicht für jede Zeile Code einen Try-Catch Block schreiben kann.
Wenn ich im Temperatur Beispiel die IllegalArgumentException verwende, kann die Klasse in Anwendungen, in der es keine Benutzereingabe der Temperatur gibt, ohne Try-Catch Block verwendet werden und in Anwendungen, wo es eine Benutzereingabe gibt, als Fehlerbehandlung mit Try-Catch Block eingesetzt werden.

checked exceptions, die bei ungültigen parametern geworfen werden, sind nicht ungewöhnlich. die hauptüberlegung dabei sollte normalerweise schlicht sein, wie einfach es ist, die parameter auf gültigkeit zu prüfen. ein einzelner integer, der nur innerhalb eines bestimmten bereichs liegen darf oder ein paramter, der nicht null sein darf, sind sehr einfach und schnell zu überprüfen. wenn aber diverse parameter in abhängigkeit zueinander stehen oder nur sehr schwer vorher zu prüfen sind (z.b. die verfügbarkeit eines netzwerks VOR der verwendung einer socket klasse), dann ist eine checked exception eine gute lösung, auch für den aufrufer.

man kann es mit den checked exceptions auch zu gut meinen. das verleitet irgendwann dazu, dass entwickler exceptions immer nur durchreichen, anstatt auf sie angemessen zu reagieren. und damit hat man dann auch nichts mehr gewonnen.

 

[maki]

checked exceptions, die bei ungültigen parametern geworfen werden, sind nicht ungewöhnlich. die hauptüberlegung dabei sollte normalerweise schlicht sein, wie einfach es ist, die parameter auf gültigkeit zu prüfen. ein einzelner integer, der nur innerhalb eines bestimmten bereichs liegen darf oder ein paramter, der nicht null sein darf, sind sehr einfach und schnell zu überprüfen. wenn aber diverse parameter in abhängigkeit zueinander stehen oder nur sehr schwer vorher zu prüfen sind (z.b. die verfügbarkeit eines netzwerks VOR der verwendung einer socket klasse), dann ist eine checked exception eine gute lösung, auch für den aufrufer.

Das Netzwerk ist kein Parameter für Socket
Selbst wenn, wie sollte man in so einem Falle reagieren?
"Netzwerkfehler" ausgeben, und dann?

Ungültige Parameter sind Programmierfehler, sollten mit unchecked Exceptions signalisiert werden (NPE, IlegalArgumentException, IllegalStateException,..)

Es ist einfach so, dass externe Resourcen wie Netzwerke und auch DBs jederzeit wegfallen können, wobei bei letzterem der Trend zu unchecked Exceptions geht (dao), ist nervig überall und jedesmal try/catch zu schreiben, wenn es sowieso keine vernünftige Möglichkeit gibt damit umzugehen...

 

[tfa]

Ich habe den Eindruck, dass checked Exceptions langsam aus der Mode kommen. Viele Frameworks wie Spring oder Hibernate werfen heute bevorzugt mit RuntimeExceptions um sich.
Vor einigen Jahren war IIRC z.B. die HibernateException noch checked - was ja auch einleuchtet, da meistens hinter einer HibernateException eine (checked) SQLException steht. Dann dachte man sich, warum sollte man jede Exception behandeln müssen, wenn sie doch meistens zu harten Fehlermeldungen führt? Ich finde das gut so, der Quelltext wird doch um einiges übersichtlicher.
Besonders nervig finde ich ja Java-Reflection. Ständig muss man 3-4 Exceptions auffangen, von denen man sicher ist, dass sie praktisch nie auftreten. Und wenn doch, ist eh alles für die Katz.