Java throws-Deklaration auf Methodenebene?

*rant*

Guten Abend

Gleich zu Beginn dies als Warnung: Mein Name ist Programm. Ich habe mich heute wieder viel mit Java herumgeschlagen und will endlich wieder mit C++, C# oder sonst was arbeiten... -,-

Zu meiner Frage: Warum muss ich überall alle Exceptions fangen oder eine throws-Deklaration machen? Ich habe möchte z.B. eine Methode aufrufen, welche laut der Deklaration eine SecurityException werfen kann. Ich weiss allerdings, dass das nicht passieren darf, da sonst das ganze Programm eh witzlos ist. Die Details sind für die Betrachtung hier komplett irrelevant.

Um diese Methode aufzurufen muss ich den ganzen Block in try-catch einbetten, oder die Deklaration selbst auch wieder auf meiner Methode anfügen. Das kocht dann so hoch, im schlimmsten Fall bis auf die Main. Warum muss das unbedingt so sein? Ich möchte ja nur eine Methode benutzen, aber mein Code hat inzwischen mehr try-catch-Blöcke als anderes...

Für mich ist es akzeptabel, wenn das ganze Programm in Flammen aufgeht, wenn eine Exception geworfen wird. Gibt es irgendwo einen lustigen Schalter, mit dem ich das erreichen kann?

icarus2

Das ist die Philosophie von Java, da unterschieden wird zwischen checked und unchecked exceptions:

A checked exception is any subclass of Exception (or Exception itself), excluding class RuntimeException and its subclasses.
Making an exception checked forces client programmers to deal with the possibility that the exception will be thrown. eg, IOException thrown by java.io.FileInputStream's read() method

Unchecked exceptions are RuntimeException and any of its subclasses. Class Error and its subclasses also are unchecked.

With an unchecked exception, however, the compiler doesn't force client programmers either to catch the exception or declare it in a throws clause. In fact, client programmers may not even know that the exception could be thrown. eg, StringIndexOutOfBoundsException thrown by String's charAt() method.

Checked exceptions must be caught at compile time. Runtime exceptions do not need to be. Errors often cannot be, as they tend to be unrecoverable.

Ich glaube nicht, dass man das ausschalten kann. Finde ich teilweise auch sehr muehsam in Java.

*rant*

Das ist zu dumm, denn es behindert mich bei meiner Arbeit. Da will man etwas ausprobieren und debuggen, und schon hagelt es tausend Fehler vom Compiler weil man eine neue Zeile Code eingefügt hat mit einem einzigen Methoden-Aufruf.

Das kann sich durchs ganze Projekt ziehen, wenn man Pech hat. Und weniger Fehler haben die Programme wegen diesem Mechanismus bestimmt nicht.

icarus2

Das ganze wird auch oft kritisiert. Hier die Argumentation, warum sich die Java-Entwickler dafuer entschieden haben:

Unchecked Exceptions — The Controversy

*rant*

icarus2 schrieb:

Das ganze wird auch oft kritisiert. Hier die Argumentation, warum sich die Java-Entwickler dafuer entschieden haben:

Unchecked Exceptions — The Controversy

Vielen Dank für den Link. Ja, sieht effektiv so aus, als ob man dagegen nichts tun könnte. Java fühlt sich für mich inzwischen so an wie damals Pascal: Mächtig, aber sehr umständlich und mit viel zu vielen Regeln. Aber ich werde weiterhin dagegen ankämpfen, irgendwann werde ich auch fertig

Reichte nicht ein throws Exception im Methodenkopf damit der Compiler Ruhe gibt?

Habe seit Jahren kein Java programmiert ... zum Glück

_kermit

µ schrieb:

Reichte nicht ein throws Exception im Methodenkopf damit der Compiler Ruhe gibt?

Habe seit Jahren kein Java programmiert ... zum Glück

Damit verlagerst du das Problem nur in die nächsthöhere Methode.

/rant/ schrieb:

Für mich ist es akzeptabel, wenn das ganze Programm in Flammen aufgeht, wenn eine Exception geworfen wird. Gibt es irgendwo einen lustigen Schalter, mit dem ich das erreichen kann?

Grundsätzlich solltest du von der Philosophie her die Exception an die Stelle weiterreichen, die angemessen mit dem Fehler umgehen kann. Wenn du das nicht möchtest, kannst du mal folgenden Hack ausprobieren:

http://projectlombok.org/disableCheckedExceptions.html

Habe es gerade kurz mit dieser Klasse getestet und der Kompiliervorgang hat tatsächlich funktioniert:

class Test {

	public static void main(String[] args) {
		myMethod();
	}

	public static void myMethod() throws Exception {
		throw new Exception();
	}
}

/rant/ schrieb:

Ich habe möchte z.B. eine Methode aufrufen, welche laut der Deklaration eine SecurityException werfen kann. Ich weiss allerdings, dass das nicht passieren darf, da sonst das ganze Programm eh witzlos ist. Die Details sind für die Betrachtung hier komplett irrelevant.

Um diese Methode aufzurufen muss ich den ganzen Block in try-catch einbetten, oder die Deklaration selbst auch wieder auf meiner Methode anfügen.

Blödsinn, eine SecurityException musst du nicht abfangen, da es eine runtime exception ist.

Das kocht dann so hoch, im schlimmsten Fall bis auf die Main. Warum muss das unbedingt so sein? Ich möchte ja nur eine Methode benutzen, aber mein Code hat inzwischen mehr try-catch-Blöcke als anderes...

Blödsinn, ein einziger try-catch Block würde natürlich reichen.

_kermit

gastantwort schrieb:

Blödsinn, eine SecurityException musst du nicht abfangen, da es eine runtime exception ist.

Damit hast du Recht. Aber ein wenig freundlicher wäre es auch gegangen, nicht?

Die meisten vernünftigen Java Libs benutzen längst nur noch Runtime Exceptions. Leider hängen grade in der JDK API an vielen Stellen noch Checked Exceptions drin.

Wenn man die nicht behandeln kann oder will, einfach try/catch drum und als RuntimeException weiterwerfen. Leider sieht man viel zu oft selbst in Produktivcode ein e.printStackTrace().