it-swarm.com.de

Warum gibt es eine NotImplementedException?

Das drängt mich wirklich, also hoffe ich, dass mir jemand eine vernünftige Begründung dafür geben kann, warum die Dinge so sind, wie sie sind.

NotImplementedException. Du ziehst an meinem Bein, oder?

Nein, ich nehme den billigen Versuch nicht, indem ich sage: "Moment mal, die Methode ist implementiert - sie löst eine NotImplementedException aus." Ja, das stimmt, Sie müssen die Methode implementieren, um eine NotImplementedException auszulösen (im Gegensatz zu einem rein virtuellen Funktionsaufruf in C++ - das ist jetzt sinnvoll!). Während das verdammt lustig ist, gibt es ein ernstes Problem in meinem Kopf.

Ich frage mich nur, wie in Gegenwart der NotImplementedException jemand mit .Net etwas anfangen kann. Müssen Sie jeden abstrakten Methodenaufruf mit einem try catch-Block abschließen, um sich vor Methoden zu schützen, die möglicherweise nicht implementiert sind? Wenn Sie eine solche Ausnahme erwischen, was zum Teufel sollen Sie damit machen?

Ich sehe keine Möglichkeit zu testen, ob eine Methode tatsächlich implementiert ist, ohne sie aufzurufen. Da das Aufrufen möglicherweise Nebenwirkungen hat, kann ich nicht alle Überprüfungen im Voraus durchführen und dann meinen Algorithmus ausführen. Ich muss meinen Algorithmus ausführen, NotImplementedExceptions abfangen und feststellen, wie meine Anwendung in einen vernünftigen Zustand zurückgesetzt wird.

Es ist verrückt. Wütend. Wahnsinnig. Die Frage ist also: Warum gibt es die NotImplementedException ?

Als Präventivschlag möchte ich nicht, dass jemand antwortet, "weil Designer dies in den automatisch generierten Code einfügen müssen". Das ist schrecklich. Ich würde lieber den automatisch generierten Code erst kompilieren, wenn Sie eine Implementierung liefern. Beispielsweise könnte die automatisch generierte Implementierung "NotImplementedException auslösen" lauten. wo die NotImplementedException nicht definiert ist!

Hat jemals jemand eine NotImplementedException abgefangen und behandelt? Haben Sie jemals eine NotImplementedException in Ihrem Code hinterlassen? Wenn ja, handelte es sich um eine Zeitbombe (dh Sie haben sie versehentlich dort gelassen) oder um einen Konstruktionsfehler (die Methode sollte nicht implementiert werden und wird niemals aufgerufen)?

Ich bin auch sehr misstrauisch gegenüber der NotSupportedException ... Nicht unterstützt? Was zum? Wenn es nicht unterstützt wird, warum ist es Teil Ihrer Benutzeroberfläche? Kann jemand bei Microsoft unsachgemäße Vererbung buchstabieren? Aber ich könnte eine andere Frage dazu stellen, wenn ich für diese nicht zu missbraucht werde.

Zusätzliche Information:

Dies ist eine interessante Lektüre zu diesem Thema.

Es scheint eine starke Übereinstimmung mit Brad Abrams zu bestehen, dass "NotImplementedException für Funktionen steht, die nur noch nicht implementiert sind, aber wirklich sollten (und werden). So etwas wie das, womit Sie beginnen, wenn Sie es sind Erstellen Sie eine Klasse, rufen Sie dort alle Methoden auf, die NotImplementedException auslösen, und spülen Sie sie dann mit echtem Code aus ... "

Kommentare von Jared Parsons sind sehr schwach und sollten wahrscheinlich ignoriert werden: NotImplementedException: Diese Ausnahme wird ausgelöst, wenn ein Typ aus einem anderen Grund keine Methode implementiert.

Das MSDN ist in diesem Punkt noch schwächer und gibt lediglich an, dass "die Ausnahme, die ausgelöst wird, wenn eine angeforderte Methode oder Operation nicht implementiert ist".

65
Daniel Paull

Es gibt eine Situation, die ich nützlich finde: TDD.

Ich schreibe meine Tests, dann erstelle ich Stubs, damit die Tests kompilieren. Diese Stubs sind nichts anderes als throw new NotImplementedException();. Auf diese Weise schlagen die Tests standardmäßig fehl, egal was passiert. Wenn ich einen Dummy-Rückgabewert verwendet habe, kann dies zu Fehlalarmen führen. Jetzt, da alle Tests kompiliert werden und fehlschlagen, weil keine Implementierung vorliegt, gehe ich mit diesen Stubs um.

Da ich niemals eine Variable NotImplementedException in einer anderen Situation verwende, wird keine Version NotImplementedException an den Freigabecode weitergegeben, da dadurch immer ein Test fehlgeschlagen ist.

Sie müssen es nicht überall fangen. Gute APIs dokumentieren die ausgelösten Ausnahmen. Das sind die, nach denen Sie suchen sollten.

EDIT: Ich habe eine FxCop-Regel geschrieben, um sie zu finden.

Dies ist der Code:

using System;
using Microsoft.FxCop.Sdk;

/// <summary>
/// An FxCop rule to ensure no <see cref="NotImplementedException"/> is
/// left behind on production code.
/// </summary>
internal class DoNotRaiseNotImplementedException : BaseIntrospectionRule
{
    private TypeNode _notImplementedException;
    private Member _currentMember;

    public DoNotRaiseNotImplementedException()
        : base("DoNotRaiseNotImplementedException",
               // The following string must be the Assembly name (here
               // Bevonn.CodeAnalysis) followed by a dot and then the
               // metadata file name without the xml extension (here
               // DesignRules). See the note at the end for more details.
               "Bevonn.CodeAnalysis.DesignRules",
               typeof (DoNotRaiseNotImplementedException).Assembly) { }

    public override void BeforeAnalysis()
    {
        base.BeforeAnalysis();
        _notImplementedException = FrameworkAssemblies.Mscorlib.GetType(
            Identifier.For("System"),
            Identifier.For("NotImplementedException"));
    }

    public override ProblemCollection Check(Member member)
    {
        var method = member as Method;
        if (method != null)
        {
            _currentMember = member;
            VisitStatements(method.Body.Statements);
        }
        return Problems;
    }

    public override void VisitThrow(ThrowNode throwInstruction)
    {
        if (throwInstruction.Expression != null &&
            throwInstruction.Expression.Type.IsAssignableTo(_notImplementedException))
        {
            var problem = new Problem(
                GetResolution(),
                throwInstruction.SourceContext,
                _currentMember.Name.Name);
            Problems.Add(problem);
        }
    }
}

Und dies ist die Regel-Metadaten:

<?xml version="1.0" encoding="utf-8" ?>
<Rules FriendlyName="Bevonn Design Rules">
  <Rule TypeName="DoNotRaiseNotImplementedException" Category="Bevonn.Design" CheckId="BCA0001">
    <Name>Do not raise NotImplementedException</Name>
    <Description>NotImplementedException should not be used in production code.</Description>
    <Url>http://stackoverflow.com/questions/410719/notimplementedexception-are-they-kidding-me</Url>
    <Resolution>Implement the method or property accessor.</Resolution>
    <MessageLevel Certainty="100">CriticalError</MessageLevel>
    <Email></Email>
    <FixCategories>NonBreaking</FixCategories>
    <Owner></Owner>
  </Rule>
</Rules>

Um dies zu bauen, musst du:

  • referenz Microsoft.FxCop.Sdk.dll und Microsoft.Cci.dll

  • Fügen Sie die Metadaten in eine Datei mit dem Namen DesignRules.xml ein und fügen Sie sie Ihrer Assembly als eingebettete Ressource hinzu

  • Benennen Sie Ihren Assembly Bevonn.CodeAnalysis. Wenn Sie unterschiedliche Namen für die Metadaten oder die Assembly-Dateien verwenden möchten, müssen Sie den zweiten Parameter entsprechend im Basiskonstruktor ändern.

Fügen Sie dann einfach die resultierende Assembly Ihren FxCop-Regeln hinzu und nehmen Sie diese verdammten Ausnahmen aus Ihrem wertvollen Code heraus. Es gibt einige Fälle, in denen eine NotImplementedException nicht gemeldet wird, wenn eine geworfen wird. Ich denke jedoch, dass Sie hoffnungslos sind, wenn Sie tatsächlich solchen Code schreiben. Für normale Zwecke, d. H. throw new NotImplementedException();, funktioniert es, und das ist alles, worauf es ankommt.

142

Es ist dazu da, einen recht allgemeinen Anwendungsfall zu unterstützen, eine funktionierende, aber nur teilweise abgeschlossene API. Angenommen, ich möchte, dass Entwickler meine API testen und bewerten - WashDishes() funktioniert, zumindest auf meinem Computer, aber ich bin noch nicht dazu gekommen, DryDishes() zu verschlüsseln, geschweige denn PutAwayDishes(). Anstatt im Hintergrund zu versagen oder eine kryptische Fehlermeldung zu geben, kann ich ganz klar sagen, warum DryDishes() nicht funktioniert - ich habe es noch nicht implementiert.

Die Schwesterausnahme NotSupportedException ist vor allem für Providermodelle sinnvoll. Viele Geschirrspülmaschinen haben eine Trocknungsfunktion, also gehört sie in die Benutzeroberfläche, aber meine Discount-Spülmaschine unterstützt sie nicht. Ich kann das über die NotSupportedException wissen lassen

40
Scott Weinstein

Ich fasse meine Ansichten an einem Ort zusammen, da sie in einigen Kommentaren verstreut sind:

  1. Sie verwenden NotImplementedException, um anzuzeigen, dass ein Schnittstellenmember noch nicht implementiert ist, dies jedoch der Fall ist. Sie kombinieren dies mit automatisierten Komponententests oder QS-Tests, um zu identifizieren, welche Funktionen noch implementiert werden müssen. 

  2. Sobald das Feature implementiert ist, entfernen Sie die NotImplementedException. Neue Komponententests werden für die Funktion geschrieben, um sicherzustellen, dass sie ordnungsgemäß funktioniert.

  3. NotSupportedException wird im Allgemeinen für Anbieter verwendet, die keine Funktionen unterstützen, die für bestimmte Typen nicht sinnvoll sind. In diesen Fällen lösen die spezifischen Typen die Ausnahme aus, die Clients fangen sie und behandeln sie entsprechend.

  4. Der Grund dafür, dass sowohl NotImplementedException als auch NotSupportedException im Framework vorhanden sind, ist einfach: Die Situationen, die zu ihnen führen, sind üblich. Daher ist es sinnvoll, sie im Framework zu definieren, sodass Entwickler sie nicht ständig neu definieren müssen. Außerdem können Kunden leicht feststellen, welche Ausnahme abzufangen ist (insbesondere im Zusammenhang mit einem Komponententest). Wenn Sie Ihre eigene Ausnahme definieren müssen, müssen sie herausfinden, welche Ausnahme abzufangen ist, was zumindest eine kontraproduktive Zeitsenkung darstellt und häufig falsch ist.

28
Mike Hofer

Warum macht die NotImplementedException existieren?

NotImplementedException ist eine großartige Möglichkeit zu sagen, dass etwas noch nicht fertig ist. Warum es nicht fertig ist, ist eine andere Frage für die Autoren der Methode. Im Produktionscode ist es unwahrscheinlich, dass Sie diese Ausnahmebedingung wahrnehmen. Wenn dies der Fall ist, können Sie sofort sehen, was passiert ist, und es ist viel besser, als herauszufinden, warum Methoden aufgerufen wurden "lustige" Nebenwirkungen.

Ist NotImplementedException das C # Äquivalent zu Javas UnsupportedOperationException?

Nein, .NET hat NotSupportedException

Ich muss meinen Algorithmus ausführen, erwischen NotImplementedExceptions und einige Wie rolle ich meine Bewerbung auf einige gesunder Staat

Eine gute API verfügt über eine XML-Methodendokumentation, die mögliche Ausnahmen beschreibt.

Ich bin der .__ sehr misstrauisch. NotSupportedException auch ... Nicht unterstützt? Was zum? Wenn es nicht .__ ist. unterstützt, warum ist es ein Teil Ihrer Schnittstelle?

Es kann Millionen Gründe geben. Beispielsweise können Sie eine neue API-Version einführen und alte Methoden nicht unterstützen. Auch hier ist es viel besser, eine beschreibende Ausnahme zu sehen, als in die Dokumentation zu blättern oder Drittanbietercode zu debuggen.

19
aku

Die Hauptverwendung für eine NotImplementedException-Ausnahme besteht im generierten Stub-Code: Auf diese Weise vergessen Sie nicht, ihn zu implementieren !! Beispielsweise implementiert Visual Studio die Methoden/Eigenschaften eines Interfaces explizit, wobei der Körper eine NotImplementedException auslöst.

12
Mitch Wheat

Re NotImplementedException - Dies dient einigen Verwendungszwecken. Es gibt eine einzige Ausnahme, die Ihre Komponententests (zum Beispiel) für unvollständige Arbeit aktivieren können. Aber es tut auch wirklich das, was sagt: Das ist (noch) nicht vorhanden. Zum Beispiel wirft "mono" all dies für Methoden aus, die in den MS-Bibliotheken existieren, aber noch nicht geschrieben wurden.

Re NotSupportedException - nicht alles ist verfügbar. Beispielsweise unterstützen viele Schnittstellen ein Paar "Können Sie das tun?"/"mach das". Wenn das "Können Sie das tun?" Gibt 'false' zurück, ist es absolut sinnvoll, dass "do this" NotSupportedException auslöst. Beispiele sind IBindingList.SupportsSearching/IBindingList.Find() usw.

8
Marc Gravell

Die meisten Entwickler bei Microsoft sind mit Entwurfsmustern vertraut, in denen eine NotImplementedException angebracht ist. Es ist eigentlich ziemlich üblich.

Ein gutes Beispiel ist ein Composite Pattern , bei dem viele Objekte als einzelne Instanz eines Objekts behandelt werden können. Eine Komponente wird als abstrakte Basisklasse für (ordnungsgemäß) geerbte Blattklassen verwendet. Beispielsweise kann eine File- und Directory-Klasse von derselben abstrakten Basisklasse erben, da sie sehr ähnliche Typen sind. Auf diese Weise können sie als einzelnes Objekt behandelt werden (was sinnvoll ist, wenn Sie sich Gedanken machen, welche Dateien und Verzeichnisse es sind - in Unix ist beispielsweise alles eine Datei). 

In diesem Beispiel würde es also eine GetFiles () -Methode für die Directory-Klasse geben. Die File-Klasse würde diese Methode jedoch nicht implementieren, da dies keinen Sinn macht. Stattdessen erhalten Sie eine NotImplementedException, da eine Datei keine untergeordneten Elemente hat wie ein Verzeichnis.

Beachten Sie, dass dies nicht auf .NET beschränkt ist - Sie werden dieses Muster in vielen OO - Sprachen und -Plattformen finden.

6
user51346

Warum haben Sie das Bedürfnis, jede mögliche Ausnahme wahrzunehmen? Packen Sie jeden Methodenaufruf auch mit catch (NullReferenceException ex) ein?

Stub-Code, der NotImplementedException wirft, ist ein Platzhalter. Wenn er freigegeben wird, sollte er genauso wie NullReferenceException ein Fehler sein.

5
orip

Es gibt wirklich keinen Grund, eine NotImplementedException catch zu machen. Wenn es getroffen wird, sollte es Ihre App töten und dies sehr schmerzhaft tun. Die einzige Möglichkeit, das Problem zu beheben, besteht nicht darin, es zu fangen, sondern den Quellcode zu ändern (entweder die aufgerufene Methode implementieren oder den aufrufenden Code ändern).

5
jeroenh

Ich denke, es gibt viele Gründe, warum MS NotImplementedException zum Framework hinzugefügt hat:

  • Zur Bequemlichkeit; da viele Entwickler es während der Entwicklung brauchen werden, warum sollten alle ihre eigenen Rollen haben?
  • Damit sich Werkzeuge auf ihre Anwesenheit verlassen können; Mit dem Befehl "Implement Interface" von Visual Studio werden beispielsweise Methodenstubs generiert, die NotImplementedException auslösen. Wenn es nicht im Framework wäre, wäre dies nicht möglich oder zumindest ziemlich umständlich (es könnte beispielsweise Code generiert werden, der erst kompiliert wird, wenn Sie Ihre eigene NotImplementedException hinzufügen)
  • Eine konsequente "Standardpraxis" fördern

Frankodwyer hält NotImplementedException für eine mögliche Zeitbombe. Ich würde sagen, dass unfertiger Code eine Zeitbombe ist, aber NotImplementedException ist viel einfacher zu deaktivieren als die Alternativen. Zum Beispiel könnten Sie Ihren Build-Server dazu veranlassen, den Quellcode für alle Verwendungszwecke dieser Klasse zu scannen und als Warnungen zu melden. Wenn Sie es wirklich verbieten möchten, können Sie Ihrem Quellcodeverwaltungssystem sogar einen Pre-Commit-Hook hinzufügen, der das Einchecken des Codes verhindert.

Sicher, wenn Sie Ihre eigene NotImplementedException werfen, können Sie sie aus dem endgültigen Build entfernen, um sicherzustellen, dass keine Zeitbomben übrig sind. Dies funktioniert jedoch nur, wenn Sie Ihre eigene Implementierung im gesamten Team konsistent einsetzen und Sie müssen sicherstellen, dass Sie sie nicht vergessen, bevor Sie sie freigeben. Möglicherweise stellen Sie auch fest, dass Sie es nicht entfernen können. Vielleicht gibt es ein paar akzeptable Anwendungen, zum Beispiel beim Testen von Code, der nicht an Kunden ausgeliefert wird.

5
oefe

Zwei Gründe:

  1. Methoden werden während der Entwicklung ausgeblendet und lösen eine Ausnahme aus, um die Entwickler daran zu erinnern, dass das Schreiben von Code nicht abgeschlossen ist.

  2. Implementieren einer Unterklassenschnittstelle, die per Entwurf eine oder mehrere Methoden der geerbten Basisklasse oder Schnittstelle nicht implementiert. (Einige Schnittstellen sind einfach zu allgemein.)

4
David R Tribble

Sie benötigen diese Ausnahme für COM-Interop. Es ist E_NOTIMPL . Das verlinkte Blog zeigt auch andere Gründe

3
MSalters

NotImplementedException ist der logischste Weg für die IDE, kompilierenden Stub-Code zu generieren. Wie wenn Sie die Schnittstelle erweitern und Visual Studio dazu bringen, es für Sie zu stubben.

Wenn Sie etwas C++/COM gemacht haben, gab es das auch dort, außer dass es als E_NOTIMPL bekannt war. 

Es gibt einen gültigen Anwendungsfall dafür. Wenn Sie an einer bestimmten Methode einer Schnittstelle arbeiten, deren Code Sie kompilieren möchten, können Sie sie debuggen und testen. Entsprechend Ihrer Logik müssten Sie die Methode von der Schnittstelle entfernen und nicht kompilierenden Stub-Code auskommentieren. Dies ist eine sehr fundamentalistische Herangehensweise, und obwohl dies verdient ist, wird oder sollte nicht jeder daran festhalten. Außerdem soll die Schnittstelle meistens vollständig sein.

Mit einer NotImplementedException können Sie feststellen, welche Methoden noch nicht fertig sind. Am Ende des Tages können Sie einfach Ctrl+Shift+F drücken, um alle Methoden zu finden. Ich bin auch sicher, dass statische Codeanalyse-Tools dies auch unterstützen werden.

Sie sind nicht dazu bestimmt, Code mit der Ausnahme NotImplementedException zu versenden. Wenn Sie der Meinung sind, dass Sie den Code verbessern können, wenn Sie ihn nicht verwenden, können Sie den Code verbessern, aber es gibt mehr produktive Maßnahmen, um die Quellqualität zu verbessern.

3
Igor Zevaka

Das klingt für mich nach einem potenziellen Minenfeld. In der fernen Vergangenheit habe ich einmal an einem alten Netzwerksystem gearbeitet, das seit Jahren ununterbrochen in Betrieb war und über einen Tag fiel. Als wir das Problem aufspürten, fanden wir einen Code, der offensichtlich noch nicht fertiggestellt war und der niemals hätte funktionieren können - buchstäblich so, als ob der Programmierer während des Codierens unterbrochen wurde. Es war offensichtlich, dass dieser spezielle Codepfad noch nie zuvor benutzt wurde.

Das Gesetz von Murphy besagt, dass etwas Ähnliches im Fall von NotImplementedException bettelt. In den heutigen Tagen von TDD usw. sollte es vor der Veröffentlichung abgeholt werden, und Sie können zumindest vor der Veröffentlichung einen Grep-Code für diese Ausnahme erstellen, aber immer noch. 

Beim Testen ist es schwierig, die Abdeckung aller Fälle zu gewährleisten, und dies hört sich an, als würde es Ihre Arbeit erschweren, indem es Laufzeitprobleme mit den möglichen Kompilierzeitproblemen machte. (Ich denke, eine ähnliche Art von "technischer Verschuldung" kommt bei Systemen vor, die stark auf "Ente-Typisierung" angewiesen sind, während ich anerkenne, dass sie sehr nützlich sind).

3
frankodwyer

Ich kann nicht für NotImplementedException einstehen (ich stimme meistens Ihrer Ansicht zu), aber ich habe NotSupportedException ausführlich in der Kernbibliothek verwendet, die wir bei der Arbeit verwenden. Mit dem DatabaseController können Sie beispielsweise eine Datenbank eines beliebigen unterstützten Typs erstellen und dann die DatabaseController-Klasse im gesamten Rest Ihres Codes verwenden, ohne sich um den Typ der darunterliegenden Datenbank zu kümmern. Ziemlich einfaches Zeug, richtig? Wo NotSupportedException hilfreich ist (und wo ich meine eigene Implementierung verwendet hätte, wenn noch keine vorhanden war), ist zwei Hauptinstanzen:

1) Migrieren einer Anwendung in eine andere Datenbank .__ Es wird oft argumentiert, dass dies selten vorkommt oder falls überhaupt erforderlich ist. Bullsh * t. Geh mehr raus.

2) Dieselbe Datenbank, anderer Treiber Das jüngste Beispiel dafür war ein Client, der eine Access-gestützte Anwendung verwendet, die von WinXP auf Win7 x64 aktualisiert wurde. Da sie kein 64-Bit-JET-Treiber ist, hat ihr IT-Mitarbeiter stattdessen die AccessDatabaseEngine installiert. Als unsere App abstürzte, konnten wir aus dem Protokoll leicht erkennen, dass DB.Connect mit NotSupportedException abstürzte - was wir schnell angehen konnten. Ein weiteres aktuelles Beispiel war einer unserer Programmierer, der versuchte, Transaktionen in einer Access-Datenbank zu verwenden. Obwohl Access Transaktionen unterstützt, unterstützt unsere Bibliothek keine Access-Transaktionen (aus Gründen, die nicht in diesem Artikel enthalten sind). NotSupportedException, es ist Ihre Zeit zu glänzen!

3) Generische Funktionen Ich kann mir hier kein kurzes "aus Erfahrung" -Beispiel vorstellen, aber wenn Sie über eine Funktion nachdenken, die einer E-Mail einen Anhang hinzufügt, möchten Sie, dass sie einige gemeinsame Dateien aufnehmen kann B. JPEGs, alles abgeleitet von verschiedenen Stream-Klassen und praktisch alles, was eine ".ToString" -Methode hat. Für den letzten Teil können Sie sicherlich nicht jeden möglichen Typ berücksichtigen, also machen Sie ihn generisch. Wenn ein Benutzer OurCrazyDataTypeForContainingProprietarySpreadsheetData übergibt, testen Sie mit Reflection, ob eine ToString-Methode vorhanden ist, und geben Sie NotSupportedException zurück, um die fehlende Unterstützung für diese Datentypen anzuzeigen, die ToString nicht unterstützen.

NotSupportedException ist keinesfalls eine entscheidende Funktion, aber ich benutze viel mehr, wenn ich an größeren Projekten arbeite.

2
nathanchere

Von ECMA-335, der CLI-Spezifikation, insbesondere den CLI-Bibliothekstypen, System.NotImplementedException, Abschnitt "Bemerkungen":

"Einige der an anderer Stelle in diesem Standard angegebenen Typen und Konstrukte sind für CLI-Implementierungen, die nur dem Kernel-Profil entsprechen, nicht erforderlich. Der Gleitkomma-Feature-Set besteht beispielsweise aus den Gleitkomma-Datentypen System.Single und System.Double: Wenn diese Unterstützung in einer Implementierung nicht unterstützt wird, führt jeder Versuch, auf eine Signatur zu verweisen, die die Gleitkomma-Datentypen enthält, zu einer Ausnahme vom Typ System.NotImplementedException. "

Die Ausnahme ist also für Implementierungen vorgesehen, die nur minimale Konformitätsprofile implementieren. Das mindestens erforderliche Profil ist das Kernel-Profil (siehe ECMA-335 - 4. Ausgabe - Partition IV, Abschnitt 3), das die BCL enthält. Aus diesem Grund ist die Ausnahme in der "Kern-API" enthalten und nicht an einem anderen Ort.

Wenn Sie die Ausnahme verwenden, um Stubbed-Methoden zu bezeichnen oder für Designer generierte Methoden ohne Implementierung, wird die Absicht der Ausnahme missverstanden.

Warum diese Informationen NICHT in der MSDN-Dokumentation für die Implementierung der CLI durch MS enthalten sind, kann ich nicht sagen.

2
Eric

Nehmen wir an, Sie haben diese Methode in Ihrem Produktionscode

public void DoSomething()

Welches würden Sie nehmen, wenn Sie es später verlassen möchten?

public void DoSomething()
{
}

oder

public void DoSomething()
{
    throw new NotImplementedException();
}

Ich würde sicher die zweite nehmen. In Verbindung mit Elmah oder einem anderen Fehlerprotokollierungsmechanismus (als Aspekt in Ihrer gesamten Anwendung implementiert). Zusammen mit Protokoll-/Ausnahmefilter zum Auslösen für kritische Fehler-E-Mail-Benachrichtigung, wenn eine davon erfasst wird.

Das Argument, dass NotImplementedException == nicht abgeschlossen ist, ist ebenfalls nicht korrekt. (1) Die Erfassung nicht implementierter Methoden sollte Unit-Tests/Integrationstests überlassen. Wenn Sie 100% ige Abdeckung haben (was Sie jetzt mit so vielen Mock/Stub/Code-Generierungswerkzeugen tun sollten), ohne NotImplementedException, was sind Ihre Sorgen? (2) Codegenerierung. Ganz einfach. Wenn ich den Code generiere und nur die Hälfte des generierten Codes verwende, warum sollte ich dann nicht NotImplementedException im Rest des generierten Stubs haben?

Es ist, als würde man sagen, dass Code nicht kompiliert werden sollte, es sei denn, jede nullfähige Eingabe sollte auf null überprüft/behandelt werden. (AKA der Billionen-Dollar-Fehler, wenn nicht mehr). Die Sprache sollte flexibel sein, während Tests/Verträge solide sein sollten.

2
Sleeper Smith

NotImplementedException

Die Ausnahme wird ausgelöst, wenn eine angeforderte Methode oder Operation nicht implementiert ist.

Wenn Sie diese Ausnahme im .NET-Kern definieren, können Sie sie leichter finden und auslöschen. Wenn jeder Entwickler einen eigenen ACME.EmaNymton.NotImplementedException erstellen sollte, wäre es schwieriger, alle zu finden.

NotSupportedException

Die Ausnahme wird ausgelöst, wenn eine aufgerufene Methode nicht unterstützt wird.

Zum Beispiel, wenn versucht wird, einen Stream zu lesen, zu suchen oder in einen Stream zu schreiben, der die aufgerufene Funktionalität nicht unterstützt.

Zum Beispiel erzeugte Iteratoren (mit dem Schlüsselwort yield) sind -a IEnumerator, aber die Methode IEnumerator.Reset löst NotSupportedException aus.

2
dalle

Sie sind beide Hacks für zwei häufige Probleme.

NotImplementedException ist eine Problemumgehung für Entwickler, die Architektur-Astronauten sind und die API zuerst aufschreiben möchten, später Code. Da dies kein inkrementeller Prozess ist, können Sie nicht alle auf einmal implementieren. Daher möchten Sie so tun, als seien Sie durch das Auslösen von NotImplementedException halbfertig.

NotSupportedException ist ein Hack um die Einschränkung der Typsysteme wie in C # und Java. In diesen Typsystemen sagen Sie, dass ein Rechteck 'eine' Form ist, wenn das Rechteck alle Shapes-Eigenschaften (einschließlich Elementfunktionen + Variablen) erbt. In der Praxis trifft dies jedoch nicht zu. Ein Quadrat ist beispielsweise ein Rechteck, aber ein Quadrat ist eine Einschränkung eines Rechtecks ​​und keine Verallgemeinerung.

Wenn Sie also das Verhalten der übergeordneten Klasse erben und einschränken möchten, werfen Sie NotSupported für Methoden aus, die für die Einschränkung nicht sinnvoll sind.

1
Afd

NotImplementedException wird für einige .NET-Methoden ausgelöst (siehe Parser C # in Code DOM, der nicht implementiert ist, aber die Methode ist vorhanden!) Sie können mit dieser Methode Microsoft.CSharp.CSharpCodeProvider.Parse überprüfen

1
Nicolas Dorier

Selten verwende ich es für die Schnittstellenfixierung. Angenommen, Sie haben eine Schnittstelle, die Sie einhalten müssen, aber bestimmte Methoden werden niemals von irgendjemandem aufgerufen. Halten Sie also eine NotImplementedException fest, und wenn jemand sie anruft, wissen sie, dass sie etwas falsch machen.

1
dr. evil

Was ist mit Prototypen oder nicht abgeschlossenen Projekten?

Ich halte das nicht für eine wirklich schlechte Idee, eine Ausnahme zu verwenden (obwohl ich in diesem Fall eine Messagebox verwende).

0
Toon Krijthe

Ich stimme etwas zu. Wenn eine Schnittstelle so erstellt wurde, dass nicht alle Klassen alle Bits davon implementieren können, sollte sie meiner Meinung nach heruntergebrochen sein.

Wenn IList nicht geändert werden kann oder nicht, sollte es in zwei Teile aufgeteilt worden sein, einer für den nicht veränderbaren Teil (Getter, Lookup usw.) und einer für den veränderbaren Teil (Setter, Hinzufügen, Entfernen usw.).

Die NotImplementedException existiert nur, um die Entwicklung zu erleichtern. Stellen Sie sich vor, Sie beginnen mit der Implementierung einer Schnittstelle. Sie möchten zumindest bauen können, wenn Sie mit der Implementierung einer Methode fertig sind, bevor Sie zur nächsten übergehen. Das Stubben der NotImplemented-Methoden mit NotImplementedExceptions ist eine großartige Möglichkeit, unvollendeten Code zu leben, der später leicht zu erkennen ist. Andernfalls laufen Sie Gefahr, schnell etwas zu implementieren, das Sie möglicherweise nicht mehr beheben können.

0
user407665

Hier ein Beispiel: Wenn Sie in Java die Schnittstelle Iterator implementieren, müssen Sie die offensichtlichen Methoden hasNext() und next() überschreiben, es gibt jedoch auch delete(). In 99% der Fälle, die ich habe, brauche ich das nicht, also werfe ich einfach eine NotImplementedException. Das ist viel besser, als nichts zu tun.

0
martinus

Ich habe einige NotImplementedExceptions in meinem Code. Oft kommt es aus einem Teil einer Schnittstelle oder einer abstrakten Klasse. Einige Methoden, die ich in der Zukunft vielleicht brauche, sind sinnvoll, da sie Teil des Unterrichts sind. Ich möchte mir jedoch einfach nicht die Zeit nehmen, etwas hinzuzufügen, wenn ich sie nicht wirklich brauche. Ich habe zum Beispiel eine Schnittstelle für alle Arten von Statistiken in meinem Spiel. Eine dieser Arten ist ein ModStat, der die Summe der Basisstat plus aller Modifikatoren (dh Waffen, Rüstung, Zauber) ist. Meine stat-Schnittstelle hat ein OnChanged-Ereignis, aber mein ModStat berechnet die Summe aller Statistiken, auf die es bei jedem Aufruf verweist. Anstatt den Overhead einer Tonne ModStat.OnChange -Ereignisse jedes Mal zu ändern, wenn sich eine Stat ändert, habe ich nur eine NotImplementedException, wenn jemand versucht, einen Listener zu OnChange hinzuzufügen/zu entfernen.

Bei .NET-Sprachen dreht sich alles um Produktivität. Warum verbringen Sie Ihre Zeit damit, etwas zu codieren, das Sie nicht einmal verwenden werden?

0
Spodi