Warum werden Ausnahmen in .NET nicht überprüft?


41

Ich weiß, googeln kann ich eine passende Antwort finden, aber ich höre lieber auf Ihre persönlichen (und vielleicht technischen) Meinungen.
Was ist der Hauptgrund für den Unterschied zwischen Java und C# beim Auslösen von Ausnahmen?
In Java muss die Signatur einer Methode, die eine Ausnahme auslöst, das Schlüsselwort "throws" verwenden, während Sie in C# in der Kompilierungszeit nicht wissen, ob eine Ausnahme ausgelöst werden kann.

44

Da die Reaktion Ausnahmen geprüft fast immer:

try { 
    // exception throwing code 
} catch(Exception e) { 
    // either 
    log.error("Error fooing bar",e); 
    // OR 
    throw new RuntimeException(e); 
} 

Wenn Sie wirklich wissen, dass es etwas, was Sie tun können, wenn eine bestimmte Ausnahme ausgelöst wird, dann sind Sie kann es fangen und dann behandeln, aber sonst ist es nur Beschwörungen, um den Compiler zu beschwichtigen.

+4

Aber wirklich, es sollte nicht sein. Viele Ausnahmen sind nicht fatal. Das Hauptproblem besteht darin, dass Checked wahrscheinlich nicht der Standardausnahmetyp sein sollte und in Java überstrapaziert wird. Aber markierte Ausnahmen können immer noch nützlich sein. 26 sep. 082008-09-26 20:11:22

+8

Wenn der Programmierer faul ist, wie ist das Javas Fehler? Wenn der Programmierer sie überstrapaziert, dann ist das ein schlechter API-Entwurf, und wieder, wie ist dieser Fehler von Java? Eine Sprache rückwärts zu biegen, um Faulheit oder Dummheit zu beschwichtigen, ist nie eine gute Idee in meinem Buch. Ich für meinen Teil glaube, dass überprüfte Ausnahmen ein nützliches Werkzeug sind, nicht mehr und nicht weniger 28 sep. 092009-09-28 16:46:06

+23

@mcjabberz das JDK verwendet sie zu sehr. Das ist Javas Schuld. 30 sep. 092009-09-30 17:49:50

  0

Java ist voll von Dogma. 24 apr. 142014-04-24 11:19:50

+1

Irgendwann möchte ich C# eine Warnung erstellen, wenn ich keine Ausnahme in meinem Code erhalte. Das wird das Leben sehr erleichtern. 10 sep. 172017-09-10 09:19:09


13

Die grundlegende Designphilosophie von C# besteht darin, dass das Abfangen von Ausnahmen selten nützlich ist, während das Bereinigen von Ressourcen in Ausnahmesituationen sehr wichtig ist. Ich denke, es ist fair zu sagen, dass using (das IDisposable-Muster) ihre Antwort auf geprüfte Ausnahmen ist. Siehe [1] für mehr.

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

1

Ich ging von Java zu C# wegen einer Jobänderung. Zuerst war ich etwas besorgt über den Unterschied, aber in der Praxis hat es keinen Unterschied gemacht.

Vielleicht liegt es daran, dass ich aus C++ komme, das die Deklaration der Ausnahme hat, aber es wird nicht häufig verwendet. Ich schreibe jede einzelne Codezeile, als ob sie werfen könnte - benutze immer herum, und denke über die Bereinigung, die ich endlich machen sollte.

Rückblickend hat mir die Verbreitung der throws-Deklaration in Java nicht wirklich etwas gebracht.

Ich möchte einen Weg zu sagen, dass eine Funktion definitiv nie wirft - ich denke, das wäre nützlicher.

+2

Es gibt ein begrenztes Ausmaß, in dem eine Funktion sagen könnte, dass sie ** definitiv ** niemals ausgelöst wird - eine Situation mit zu wenig Speicher könnte z. B. praktisch überall zu einer OutOfMemoryException führen. Vielleicht könnte eine Funktion behaupten, sie würde niemals "absichtlich" werfen - aber wie viel würde das sein? Was können Sie sinnvollerweise mit einer solchen Forderung tun? 12 jun. 092009-06-12 15:26:04


1

Zusätzlich zu den Antworten, die bereits geschrieben wurden, hilft es Ihnen in vielen Situationen nicht, Ausnahmen zu überprüfen. Überprüfte Ausnahmen erschweren die Implementierung von Generika. Wenn Sie die Abschlussvorschläge gelesen haben, werden Sie feststellen, dass jeder einzelne Abschlussvorschlag auf ziemlich hässliche Art und Weise um geprüfte Ausnahmen herum arbeiten muss.


10

Als .NET entwickelt wurde, hatte Java Ausnahmen seit geraumer Zeit überprüft und diese Funktion von Java-Entwicklern bestenfalls als controversialcontroversial angesehen wurde. Also .NET-Designer chose nicht in C# Sprache zu integrieren.

  0

sieht aus wie lustig, aber ich denke, das ist wahr und ist der eine der Hauptgrund, dass C# Design-Sprache-Team uns nie sagen wird :) 18 mai. 122012-05-18 17:38:32

  0

sieht aus wie die Andersnoras.com Link ist pleite 30 sep. 152015-09-30 04:21:56


4

Interessanterweise haben die Forscher von Microsoft Research Ausnahmen zu Spec#, ihre Obermenge von C# hinzugefügt.

+2

Da ich nicht genug rep haben Um die Antwort zu bearbeiten, hier ist ein Link zu speC# info: http://research.microsoft.com/SpecSharp/ 23 sep. 082008-09-23 22:38:33


1

Ich vermisse manchmal überprüft Ausnahmen in C# /. NET.

Ich nehme außer Java keine andere bemerkenswerte Plattform hat sie. Vielleicht sind die .NET Jungs einfach mit dem Flow gegangen ...

+1

Das Problem ist, dass sehr wenige Programmierer tatsächlich überprüft Ausnahmen verwenden, wie sie entworfen sind. Es ist ein Fall von Ideal gegen Praxis. Im Idealfall getestete Ausnahmen sind sehr hilfreich, aber in der Praxis fügen sie meistens zusätzliche Arbeit für den Programmierer hinzu. 23 sep. 082008-09-23 22:56:14

+3

Folgende ideale Praktiken erfordern ideale Programmierer. 23 sep. 082008-09-23 23:27:39

+1

@Constantin: ... oder eine Klasse oder zwei in API-Design 28 sep. 092009-09-28 16:49:59


92

In dem Artikel The Trouble with Checked Exceptions und in Anders Hejlsberg der (Designer der Sprache C#) eigene Stimme, gibt es drei Hauptgründe für C# nicht Ausnahmen geprüft Stützen, wie sie in Java gefunden und verifiziert:

  • neutral auf Checked Ausnahmen

    „C# ist auf dem geprüften Ausnahmen Problem im Grunde still. Sobald eine bessere Lösung bekannt-und glauben Sie mir, wir , darüber nachzudenken, weiterhin it-wir können zurück gehen und tatsächlich etwas in Stelle setzen.“

  • Versionierung mit Checked Ausnahmen

    "Das Hinzufügen einer neuen Ausnahme zu einer throws -Klausel in einer neuen Version bricht den Code des Clients. Es ist wie das Hinzufügen einer Methode zu einer Schnittstelle. Nachdem Sie eine Schnittstelle veröffentlichen, ist es für alle praktischen Zwecke unveränderlich, ...“

    „Es ist lustig, wie die Leute denken, dass die wichtige Sache, über Ausnahmen ist Umgang mit ihnen. Das ist nicht die wichtige Sache über Ausnahmen. In einer gut geschriebenen Anwendung gibt es ein Verhältnis von zehn zu eins, meiner Meinung nach versuchen Sie endlich, versuchen zu fangen. Oder in C#, using Aussagen, die sind wie schließlich versuchen.“

  • Skalierbarkeit von aufgegebener Ausnahme

    „In dem kleinen, überprüften Ausnahmen sind sehr verlockend ... Das Problem beginnt, wenn Sie beginnen, große Systeme zu bauen, wo Sie mit vier oder fünf verschiedenen Subsystemen sprechen. Jedes Subsystem löst vier bis zehn Ausnahmen aus. Nun, jedes Mal, wenn Sie gehen die Leiter der Aggregation, haben Sie diese exponentielle Hierarchie unter Ihnen der Ausnahmen, die Sie haben, zu beschäftigen. Am Ende müssen Sie 40 Ausnahmen deklarieren, die Sie werfen könnten. ... Es ist nur Ballons außer Kontrolle geraten.“

In seinem Artikel‚Why doesn't C# have exception specifications?‘, Anson Horton (Visual C# Programm-Manager) listen auch die folgenden Gründe (die Artikel Details zu jedem Punkt e):

  • Versionierung
  • Produktivität und Codequalität
  • Unpraktizierbarkeit des Klassenautors differenzieren zwischen geprüft und nicht markiert Ausnahmen
  • Schwierigkeit der Bestimmung der richtigen Ausnahmen für Schnittstellen.

Es ist interessant, dass C# zu beachten ist, dennoch über den <exception>-Tag und der Compiler nimmt geworfen Dokumentation von Ausnahmen von einem bestimmten Verfahren unterstützen sogar die Mühe zu überprüfen, ob der referenzierte Ausnahmetyp tatsächlich existiert. Es wird jedoch keine Überprüfung an den Call-Standorten oder die Verwendung der Methode durchgeführt.

Sie auch in die Exception Hunter aussehen sollen, die von Red Gate Software ein Handel Werkzeug ist, die statische Analyse verwendet, die durch ein Verfahren ausgelöste Ausnahmen zu bestimmen und zu berichten und die möglicherweise nicht abgefangene kann gehen:

Exception Hunter ist eine neue Analyse Werkzeug, das die Menge von möglichen Ausnahmen findet und meldet Ihre Funktionen könnte werfen - bevor Sie sogar versenden. Mit ihm können Sie unbehandelt Ausnahmen leicht und schnell zu finden, bis die Zeile des Codes, der die Ausnahmen wirft. Sobald Sie die Ergebnisse haben, können Sie entscheiden, welche Ausnahmen behandelt werden müssen (mit Ausnahme Ausnahme Handling-Code), bevor Sie Ihre Anwendung in die Wildnis freigeben.

Schließlich Bruce Eckel, Autor von Thinking in Java, hat einen Artikel namens „Does Java need Checked Exceptions?“, die als gut zu lesen up wert sein kann, weil die Frage, warum checked Ausnahmen gibt es nicht in C# in der Regel root in Vergleiche zu Java nimmt .

  0

Ich bin total verkauft auf * Versionierung mit aktivierten Ausnahmen * und * Versionierung mit aktivierten Ausnahmen * Punkte. 20 dez. 092009-12-20 14:45:45

+2

Interessanterweise tendieren viele Entwickler nach meiner Erfahrung dazu, den Teil "Sobald eine bessere Lösung bekannt ist" zu ignorieren. Jetzt, im Jahr 2015, fast 12 Jahre nach dieser Aussage, habe ich keine bessere Lösung in C# oder einer anderen Sprache wie Kotlin usw. gesehen. (Oder habe ich es vermisst? Ich programmiere derzeit nicht mehr in C#.) Und Wenn man nur geprüfte Ausnahmen entfernt, ohne eine bessere Lösung zu haben, wird das Denken schlechter, IMHO, nicht besser. Wir hatten eine schlechte Zeit in einer unserer C# -Anwendungen nach einigen Refactorings, um zu überprüfen, ob die Exceptions in allen Fällen richtig behandelt werden, weil der Compiler es nicht sagen würde. 01 jun. 152015-06-01 10:33:17

  0

Mit der Versionierung würde die Antwort nur darin bestehen, eine geprüfte Ausnahme nicht in eine neue Version zu werfen, es sei denn, dies ist absolut notwendig. Ich würde dem nicht zustimmen und sagen, dass Java über geprüfte Ausnahmen schweigt und C# eigenmächtig ist. I.E. Mit Java können Sie eine geprüfte Ausnahme oder eine Laufzeitumgebung auslösen, die Entscheidung bleibt Ihnen überlassen, während C# Sie zwingt, eine Laufzeitausnahme auszulösen. Es klingt, als ob seine Argumentation darauf hinausläuft, dass "geprüfte Ausnahmen missbraucht werden, also lassen wir sie nicht verwenden". 17 okt. 162016-10-17 15:06:47

+1

Dies sollte die akzeptierte Antwort sein. 06 sep. 172017-09-06 15:24:41

  0

Wenn IDE oder Compiler eine Warnung für Ausnahmen erstellen, die nicht mit dem Programmierer behandelt werden, wird die Software robuster und Laufzeitfehler werden reduziert. 10 sep. 172017-09-10 09:24:27


8

Grundsätzlich ist eine Eigenschaft der Aufrufer, ob eine Ausnahme behandelt werden soll oder nicht, und nicht der Funktion.

Zum Beispiel gibt es in einigen Programmen keinen Wert bei der Behandlung einer IOException (Ad-hoc-Befehlszeilen-Dienstprogramme zum Ausführen von Datenverarbeitung betrachten; sie werden nie von einem "Benutzer" verwendet werden, sie sind spezialisierte Tools von Fachpersonen verwendet). In einigen Programmen ist es sinnvoll, eine IOException an einem Punkt "in der Nähe" des Aufrufs zu verarbeiten (wenn Sie beispielsweise einen FNFE für Ihre Konfigurationsdatei erhalten, werden Sie auf einige Standardwerte zurückgreifen oder an einem anderen Ort oder etwas davon suchen) Natur). In anderen Programmen möchten Sie, dass es lange vor der Verarbeitung aufbläht (z. B. möchten Sie es möglicherweise abbrechen, bis es die Benutzeroberfläche erreicht. An diesem Punkt sollte es den Benutzer warnen, dass etwas schiefgelaufen ist.

dieser Fälle ist abhängig von der Anwendung, und nicht die Bibliothek.Und dennoch, mit geprüften Ausnahmen, ist es die Bibliothek, die die Entscheidung trifft. Die Java-E/A-Bibliothek trifft die Entscheidung, dass sie überprüfte Ausnahmen verwendet (was die Handhabung des Anrufs lokal unterstützt), wenn in einigen Programmen eine bessere Strategie eine nicht lokale Behandlung oder gar keine Behandlung ist. Das zeigt den wahren Fehler mit geprüften Ausnahmen in der Praxis, und es ist weit fundamentaler als der oberflächliche (wenngleich auch wichtige) Fehler, dass zu viele Leute dumme Ausnahme-Handler schreiben, nur um den Compiler zum Schweigen zu bringen. Das Problem, das ich beschreibe, ist ein Problem, selbst wenn erfahrene, gewissenhafte Entwickler das Programm schreiben.

+1

+1. Die Überprüfung sollte eine Funktion der Beziehung zwischen den Call- und Catch-Sites sein. Viele Methoden geben an, dass bestimmte Ausnahmen anstelle einer Rückgabe verwendet werden, wenn bestimmte unerwartete Bedingungen auftreten. Zum Beispiel, IDictionary.Add() 'gibt an, dass eine Implementierung 'ArgumentException' auslösen soll, wenn ein Schlüssel bereits existiert. Leider gibt es keine Möglichkeit, eine Ausnahme, die aus diesem Grund ausgelöst wird, von einer 'ArgumentException' zu unterscheiden, die von einer Methode ausgelöst wird, die von den' Dictionary.Add() '- Implementierungen unter Umständen aufgerufen wird, die sie nicht erwartet hat. 29 okt. 122012-10-29 20:04:01

+1

Wenn ich ein Ausnahmesystem entwickeln würde, hätte ich ein paar diskrete (wahrscheinlich versiegelte) systemdefinierte Ausnahmetypen, aber keine Ausnahmetypen als primäres Mittel, um zu entscheiden, was zu fangen ist. Stattdessen würde das Ausnahmeobjekt ein oder mehrere Objekte einer abstrakten 'ExceptionInfo'-Klasse umbrechen. Die von 'IDictionary.Add' ausgelöste Ausnahme könnte mit' ExpectedException' beginnen, die eine 'DuplicateKeyExceptionInfo' enthält, aber wenn sie durch einen Layer geleitet wird, der sie nicht erwartet hat, wird sie zu einer' UnexpectedException', die dasselbe Objekt enthält. 29 okt. 122012-10-29 20:11:17

  0

Geprüfte Ausnahmen können missbraucht werden, aber ich würde widersprechen, dass es schwierig sein kann zu wissen, welche Ausnahmen von einer Funktion in C# ausgelöst werden. einen Entwickler zu verführen, zu fangen (Exception) ... was auch eine Sünde ist. Wenn C# oder Visualstudio einen Weg finden, um zu sehen, welche Exceptions ausgelöst werden können, dann würde ich zustimmen, dass unchecked der richtige Weg ist. 17 okt. 162016-10-17 15:16:32


2

Anders selbst beantwortet diese Frage in this episode des Software Engineering Radio Podcast