| 

.NET C# Java Javascript Exception

2
Java kennt sogenannte CheckedExceptions, wo ich bei jeder Methode mit throws angeben muss, welche Exceptions ich erwarten muss. Gibt es das in C# nicht? Ich habe jedenfalls nichts gefunden, fand das in Java aber immer ganz praktisch. Warum gibt es die denn in C# anscheinend nicht?
News:
28.05.2011
Bonnholz 21 2
4 Antworten
2
Hier ist ein Interview mit Anders Hejlsberg, dem Schöpfer von C#, zu dem Thema.
30.05.2011
Noffls 215 4
+1 Danke für den Link!
Matthias Hlawatsch 30.05.2011
0
Hallo,

warum das so ist frägst du am besten Anders Hejlsberg ;-)
Aber mit den Contracts lässt sich ähnliches erreichen - sofern ich die CheckedExceptions richtig verstanden habe.

mfG Gü
28.05.2011
gfoidl 9,4k 3 5
Spec# implementiert laut wikipedia explizit die CheckedExceptions: http://de.wikipedia.org/wiki/Spec-Sharp
Sparky 03.06.2011
0
Das Fehlen von Checked Exceptions entbindet den Programmierer von einer Verantwortung. Wenn ein Programmierer Checked Exceptions verwendet sind Design-Entscheidungen zu treffen. Er muss sich darüber Gedanken machen, welche Exceptions essentiell für den Aufrufer sind und welche sich vorerst außerhalb der Möglichkeiten der Behandlung durch den Aufrufer befinden (sollen). Diese Designentscheidung und Verantwortung, essentielle Ausnahmen zu proklamieren, wird dem Programmierer weggenommen und in die Dokumentation (A****-an-die-Wand-Dokumentation) verlagert. Eine Compiler-Unterstützung gibt es dann nicht.

Zu JAVA:

Checked Exceptions sind für viele Programmierer ein Dorn im Auge. Sie fordern die Behandlung einer bestimmten Programmsituation, was insbesondere bei gesetzten Vorbedingungen, die Fehler ausschließen, extrem nervig ist.

Aus meiner Sicht sind Checked Exceptions die nerven ein Anzeichen für falsches API Design. Die API berücksichtigt dann die Art der Verwendung nicht.

Negativ-Beispiel: SQLException. Es handelt sich hierbei um eine Checked Exception, die bei fast jedem Aufruf einer Methode im JDBC-Kontext behandelt werden muss (ResultSet, Statement, Connection). Eine Ausnahme wird von dem API-Designer als Regel aufgefasst. Dies ist ein grober Design-Fehler. Entsprechende Abstraktions-Frameworks wie Hibernate zeigen hier Einsicht und geben entsprechende Exceptions gekapselt in RuntimeExceptions zurück.

Positiv-Beispiel: ArrayIndexOutOfBoundsException, NoSuchElementExcepion. Bei String-Operationen wird davon ausgegangen, dass der Aufrufer die Bedingungen for dem Aufruf von subtring-Operationen die Korrektheit der Parameter prüft, was man üblicherweise auch immer macht. Die NoSuchElementException kannbei einem Iterator verhindert werden, wenn man vorher die hasNext-Methode abfragt. Deshalb handelt es sich bei beiden Exceptions sinnigerweise um RuntimeExceptions.

Positiv-Beispiel: Reflection-API (ClassNotFoundException, InstantiationException, IllegalAccesException, ...). Diese Exceptions sind Checked Exceptions. Sie teilen dem Aufrufer sinnvoll mit, was schieflaufen kann. Sie besitzen einen aussagekräftigen Namen, der die Ursache leicht eingrenzen lässt. Die Reflection-API sollte nur in Spezialfällen konsultiert werden und nicht in der Regel Anwendung finden. Damit kommt der Entwickler nie in die Situation, diese Exceptions als nervig zu empfinden.

Aus meiner Sicht gehören Checked Exceptions zum guten Ton. Das Fehlen dieses Konstrukts in anderen Sprachen ist aus meiner Sicht der Popularität geschuldet. Der Wunsch ist häufig, straight forward zu entwickeln. Ausnahmen werden dann behandelt, wenn sie auftreten. Es werden zwei verschiedene Fehlertypen über einen Kamm geschert: Datenkonstellationen, die durch externe Systeme (z.B. Benutzer) erzeugt werden, die der Entwickler nicht beachtet hat und Datenkonstellationen und Abläufe, die der Programmierer selber erzeugt hat, die zu Fehlern führen. Bei fehlenden Checked Exceptions fehlt meiner Meinung nach die planerische Tätigkeit, welche theamtisch bezogene Ausnahmesituationen auf ein Piece of Work zukommen kann.

Im Endeffekt hat der Programmierer es ersteinmal einfacher, da ihm Verantwortung abgenommen wird. Er braucht sich nicht um Ausnahmesituationen zu scheren, wenn er nicht möchte. Aber Verantwortung kann genauso wie Energie nicht verschwinden, sondern nur umgesetzt werden. In diesem Fall wird die Verantwortung auf nachfolgende Schichten oder Projektphasen (Test, Produktiv) verteilt. Eine falsche Faulheit wird proklamiert, die dann am Ende darin endet, dass dem Endbenutzer empfohlen wird, die Eingabe bestimmter Daten zu unterlassen, damit er das System nicht in einen inkonsistenten Zustand bringt...
30.05.2011
oopexpert 455 1 8
0
Ich stimme zu, dass dem Thema "geplante Fehlerbehandlung" zu wenig Beachtung geschenkt wird, allerdings sehe ich bei CheckedExceptions ein großes Problem: Abhängigkeiten.

Wenn ich eine Exception nicht am Ort ihres Auftretens fangen will, sondern dort wo es sinnvoll ist (da ich so den Code nicht zerhacke und weil eben nicht jede Klasse, die eine (3rdParty?) Helferklasse verwendet auch deren Exceptions verarbeiten muss und soll), dann habe ich ganz schnell die ganze Klassenhierarchie hinauf zu der Klasse, welche die Exception bearbeitet eine Abhängigkeit von dieser Exception. Man injiziert Abhängigkeiten, wo sie nicht gebraucht werden und nur stören. Das wiederspricht dem Single Responsibility Prinzip, nach dem sich eine Klasse nur aus einem Grund ändern sollte (auf eine Verantwortlichkeit bezogen) - hier wäre noch eine zweite Verantworlichkeit vorhanden: Die Klasse reicht eine Exception durch und müsste bei einer Änderung der Exception-Signatur oder ähnlichem geändert werden.
30.05.2011
Sparky 109 3
Ich sehe bei korrektem API Design kein Problem mit Abhängigkeiten. Wenn es in einem Benutzersystem die Konsistenzbedingung gibt, dass es Benutzernamen eindeutig sein müssen, erwarte ich, dass ich, dass ein Konflikt mir in Form einer DoppelterBenutzernameException kenntlich gemacht wird. Gibt es irgendwann zusätzlich noch eine Einschränkung von den verwendeten Zeichen im Benutzernamen, wird eine weitere Exception proklamiert, usw. Un ich erwarte, dass der Aufrufer diese Ausnahmen in seinem Code berücksichtigt.
oopexpert 01.06.2011
Dem will ich ja gar nicht wiedersprechen! Das sehe ich ganz genauso. Dem Vorteil einer Erzwungenen Beachtung (und das für alle Klassen, die in der Klassenhierarchie höher stehen) steht aber der Nachteil einer verschlechterten Evolvierbarkeit der Software gegenüber. Das wollte ich herausstellen. Nicht mehr, nicht weniger.
Sparky 01.06.2011

Stelle deine .net-Frage jetzt!