Warum wurde die "throws"-Klausel von Java (in der Methodendeklaration) nicht in C# aufgenommen?

Question

Warum wurde die "throws"-Klausel von Java (in der Methodendeklaration) nicht in C# aufgenommen?

Answer 1

Anders Hejlsberg (der leitende C#-Architekt) erklärt es in diesem Interview:

http://www.artima.com/intv/handcuffs.html

Answer 2

(Zusätzlich zu Patriks etwas definitiver Antwort.)

Geprüfte Ausnahmen in Java sind ein sehr kontroverses Thema. Ich habe sie geliebt und beim Schreiben von C# sehr vermisst. Es fühlte sich an, als ob ich ohne Sicherheitsgurt fahren würde. Jetzt ärgern sie mich... denn obwohl sie in der Theorie nach einer guten Idee klingen, haben sie definitiv hat mir viel Kummer bereitet, aber keinen greifbaren Nutzen gebracht. Ich kann mich nicht erinnern immer einen Fehler im C#-Code zu finden, vor dem mich geprüfte Ausnahmen bewahrt hätten. Das heißt nicht, dass es nicht passieren kann, aber es ist mir nicht passiert.

Das Ärgerliche daran ist, dass es sich in mancher Hinsicht so anfühlt, als sei C# zu lasch - aber dass der Ansatz von Java nicht ganz der richtige ist. Es ist, als gäbe es eine bessere Lösung, die darauf wartet, entdeckt zu werden, und der Versuch von Java war ein gutes Experiment, das aber nicht ganz funktioniert hat.

Answer 3

Ich denke, dass geprüfte Ausnahmen als ein Sprachmerkmal einige der kulturellen Unterschiede zwischen Microsoft und Sun aufzeigen.

Microsoft ist zum größten Teil ein Kundenunternehmen. Die meiste Software, die sie herstellen, und auf die ihr Entwicklungsstack ausgerichtet ist, ist Client-Software.

Ja, ja, ich weiß, dass Microsoft Server-Software herstellt. Aber Office und Windows sind gemessen am Umsatz VIEL größer als Windows Server und Exchange.

Ich denke, man kann mit Fug und Recht behaupten, dass die meiste Software, die in .NET (und noch mehr mit VB 6) geschrieben wird, Client-Software ist. Sicher, ein großer Teil davon ist Web-Software, die auf einem Web-Server läuft, aber das meiste davon ist wirklich ... "clienty type web apps". Ich würde sagen, die meisten Webanwendungen sind eher wie "Word" als wie Exchange.

Und ja, ich weiß, dass es WCF- und SOAP-Dienste und dergleichen gibt, aber das sind in der Regel nur "Middleware" für "Clienty"-Sachen.

Sun hingegen ist in erster Linie ein Server-Unternehmen. Ihre Software ist nicht gerade die beste, wenn es um die Benutzeroberfläche geht (das ist keine Beleidigung für Unix... nur für Solaris...). Mac OS X basiert auf Unix und hat eine phänomenale Benutzeroberfläche, der Unterschied zwischen den beiden ist, dass Sun nicht so viel Wert auf die Benutzeroberfläche legt wie Apple). Sie verkaufen sogar THIN CLIENTS, die versuchen, alles auf den Server zu verlagern.

Also... auf jeden Fall... Microsoft ist hauptsächlich ein Client-Unternehmen, und Sun ist hauptsächlich ein Server-Unternehmen.

Wenn man Serversoftware schreibt, ist Zuverlässigkeit ein wichtiges Thema. Sie ist enorm wichtig. Wenn ein E-Mail-Server zusammenbricht, bekommen die Leute keine E-Mails, und das Geschäft kommt zum Erliegen. Daher ist es für den Verkauf eines E-Mail-Servers wichtig, sicherzustellen, dass der Server mit den meisten Fehlern, die auftreten können, intelligent umgehen kann.

Bei Client-Software ist Zuverlässigkeit wichtig, aber nicht annähernd so wichtig wie bei Server-Software. Solange die meisten Mainline-Szenarien funktionieren, sind die Leute zufrieden. In vielen Fällen können verrückte Randszenarien einfach ignoriert oder generisch behandelt werden.

Der Schlüssel zu einer hohen Zuverlässigkeit liegt darin, dass Sie alle möglichen Randfälle berücksichtigen, die auftreten können. Was passiert, wenn wir die Datenbankdatei nicht öffnen können, weil sie von einem anderen Prozess gesperrt ist, oder wir keine Leseberechtigung haben? Was ist, wenn der Speicher oder der Festplattenplatz knapp wird? Was passiert, wenn der Strom ausfällt, während wir diese Prozedur ausführen?

Bei wirklich hohen Zuverlässigkeitsanforderungen KANN es hilfreich sein, Ausnahmen zu prüfen. Wenn es ein Szenario gibt, das Sie nicht vorhergesehen haben, und es für Ihr Unternehmen wichtig ist, dass Sie alles vorhersehen, dann sagt Ihnen der Compiler ... "Hey, du hast die RocketFuelExhaustedException nicht behandelt" wäre hilfreich.

Ich denke also, dass die überprüften Ausnahmen aus der Sicht von Sun als Serveranbieter stammen.

Für Microsoft als Kundenunternehmen, das Entwicklertools an Kunden-Softwareentwickler verkauft, sind geprüfte Ausnahmen natürlich furchtbar ärgerlich und behindern die eigentliche Arbeit.

Das sind jedenfalls meine $0,02...

Answer 4

Der Hauptgrund ist, dass die C#-Designer beschlossen haben, keine "geprüften Ausnahmen" zu verwenden. Das bedeutet, dass der Entwickler keine Klausel zum Auslösen von Ausnahmen in einen try-catch-Block einbauen muss. Es wurde davon ausgegangen, dass dies nur für kleine Anwendungen hilfreich ist und keinen wirklichen Nutzen für größere Projekte hat. Außerdem wurden geprüfte Ausnahmen von den Entwicklern missbraucht, die ständig leere Catch-Blöcke verwenden. Da es keine geprüften Ausnahmen gibt, gibt es für eine Methode keinen Grund zu deklarieren, welche Ausnahmen geworfen werden können.

Die Verwendung oder Nichtverwendung von "geprüften Ausnahmen" ist ein kontroverses Thema, aber die meisten scheinen sich einig zu sein, dass es keinen Bedarf dafür gibt. Spring, ein bekanntes Java-Framework, verwandelt geprüfte Ausnahmen in Laufzeitausnahmen.

Answer 5

Ausnahmen sind offensichtlich "außergewöhnliche" Ereignisse. In den Paradigmen von .net sollten Ausnahmen niemals auftreten (deshalb gibt es Methoden wie TryParse ...), so dass es wenig Sinn macht, gezwungen zu sein, Ereignisse zu behandeln, die ohnehin nicht auftreten sollten.