Warum existiert NotImplementedException?

Es ist eine situation, die ich nützlich finden: TDD.

Schreibe ich meine Prüfungen, dann Erzeuge ich stubs, so dass die tests kompilieren. Diese stubs nichts zu tun, sondern throw new NotImplementedException();. Auf diese Weise werden die tests fehlschlagen, standardmäßig, egal was. Wenn ich "dummy" - Rückgabewert könnte es erzeugen false positives. Nun, dass alle tests kompilieren und scheitern, weil es keine Implementierung, die ich bekämpfen diese stubs.

Da ich nie ein NotImplementedException in jeder anderen situation, keine NotImplementedException je pass auf Freigabe-code, da wird es immer machen Sie einige test fehlschlagen.

Brauchen Sie nicht, um es zu fangen alle über dem Platz. Gute APIs Dokument die Ausnahmen geworfen. Das sind die, die Sie suchen sollten.

EDIT: ich schrieb eine FxCop Regel, 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>

Aufzubauen, brauchen Sie:

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

• Legen Sie die Metadaten in eine Datei namens DesignRules.xml und fügen Sie es als eingebettete Ressource der assembly

• Namen Ihrer Versammlung Bevonn.CodeAnalysis. Wenn Sie möchten, verwenden Sie unterschiedliche Namen für die Metadaten oder die assembly-Dateien, stellen Sie sicher, dass der zweite parameter der Basis-Konstruktor entsprechend.

Dann einfach fügen Sie die resultierende assembly auf Ihrer FxCop-Regeln, und diese verdammten Ausnahmen Ihre kostbare code. Es gibt einige Ausnahmefälle, wo es nicht Bericht eine NotImplementedException, wenn man geworfen wird, aber ich glaube wirklich, Sie sind hoffnungslos, wenn Sie tatsächlich das schreiben solcher cthulhian code. Für den normalen verwendet, also throw new NotImplementedException();es funktioniert, und das ist alles was zählt.

InformationsquelleAutor der Antwort R. Martinho Fernandes

Ich fasse meine Ansichten über dies an einem Ort, da Sie verstreut ein paar Kommentare:

1. Verwenden Sie NotImplementedException zu zeigen, dass eine Schnittstelle Mitglied ist noch nicht implementiert, werden es aber sein. Kombinieren Sie diese mit automatisierten unit-Tests oder QA-Test zum identifizieren von features, die noch umgesetzt werden müssen.

2. Sobald das feature implementiert ist, entfernen Sie die NotImplementedException. Neue unit-tests geschrieben werden, die für die Funktion, um sicherzustellen, dass es ordnungsgemäß funktioniert.

3. NotSupportedException ist in der Regel für die Anbieter, die unterstützen keine Funktionen, die nicht Sinn machen, für bestimmte Arten. In diesen Fällen, die bestimmte Arten werfen die Ausnahme, die Kunden zu fangen und behandeln Sie diese entsprechend.

4. Dem Grund, dass beide NotImplementedException und NotSupportedException existieren im Framework ist einfach: die Situationen, die zu Ihnen führen, sind Häufig, so macht es Sinn, Sie zu definieren, die im Rahmen, so dass sich Entwickler nicht ständig neu definieren. Auch, es macht es einfach für die Kunden zu wissen, die Ausnahme zu fangen (vor allem im Rahmen eines unit-test). Wenn Sie zum definieren Ihrer eigenen Ausnahme, Sie haben, um herauszufinden, die Ausnahme zu fangen, das ist zumindest ein Zähler-produktive Zeit sinken, und Häufig falsch.

InformationsquelleAutor der Antwort Mike Hofer

Den wichtigsten nutzen für eine NotImplementedException Ausnahme ist das generierte stub-code: so dass Sie nicht vergessen, es zu realisieren!! Zum Beispiel, Visual Studio wird explizit eine Schnittstelle implementieren, die Methoden/Eigenschaften, die mit dem Körper werfen eine NotImplementedException.

InformationsquelleAutor der Antwort Mitch Wheat

Meisten Entwickler bei Microsoft sind vertraut mit design-mustern, in denen eine NotImplementedException geeignet ist. Es ist ziemlich normal eigentlich.

Ein gutes Beispiel ist ein Composite-Musterwo viele Objekte behandelt werden kann, als eine einzelne Instanz eines Objekts. Eine Komponente wird als Basis verwendet abstrakte Klasse für (richtig) vererbt leaf-Klassen. Zum Beispiel, eine Datei-und Directory-Klasse Erben können von der gleichen abstrakten Klasse, weil Sie sehr ähnliche Arten. Auf diese Weise können Sie behandelt werden wie ein einzelnes Objekt (was Sinn macht, wenn Sie darüber nachdenken, welche Dateien und Verzeichnisse in Unix zum Beispiel, alles ist eine Datei).

So, in diesem Beispiel, es wäre eine GetFiles () - Methode der Directory-Klasse, aber die File-Klasse implementiert diese Methode, weil es nicht sinnvoll ist, dies zu tun. Stattdessen erhalten Sie eine NotImplementedException , weil eine Datei nicht, die Kinder haben die Möglichkeit ein Verzeichnis führt.

Beachten Sie, dass dies ist nicht beschränkt .NET - Sie stoßen werden diese Muster in vielen OO-Sprachen und Plattformen.

InformationsquelleAutor der Antwort

Ich denke, es gibt viele Gründe, warum MS Hinzugefügt NotImplementedException zu dem Rahmen:

• Als Komfort, da viele Entwickler müssen es während der Entwicklung, warum sollte jeder haben, Rollen Sie Ihre eigenen?
• So, dass die Werkzeuge verlassen können, auf seine Präsenz; zum Beispiel die Visual Studio - "Schnittstelle Implementieren" - Befehl Methode generieren stubs, die werfen NotImplementedException. Wenn es nicht im Rahmen, würde dies nicht möglich sein, oder zumindest eher umständlich (zum Beispiel, könnte es generiert code, der nicht kompiliert, bis Sie fügen Sie Ihre eigenen NotImplementedException)
• Zu ermutigen, eine einheitliche "standard-Praxis"

Frankodwyer denkt NotImplementedException als eine potenzielle Zeitbombe. Ich würde sagen, dass alle unfertigen code ist eine Zeitbombe, aber NotImplementedException ist viel einfacher zu Entwaffnen, als die alternativen. Zum Beispiel könnten Sie haben Ihr build-server Scannen Sie den Quellcode für alle Anwendungen dieser Klasse, und melden Sie als Warnungen. Wenn Sie wollen, um wirklich verbieten es, Sie konnte sogar noch ein pre-commit-hook auf Ihrer source-control-system, das verhindert, dass checkin code.

Sicher, dass, wenn Sie Rollen Sie Ihre eigenen NotImplementedException, können Sie es entfernen, aus dem letzten build, um sicherzustellen, dass keine Zeit Bomben übrig sind. Dies wird aber nur funktionieren, wenn Sie Ihre eigene Implementierung konsequent in das gesamte team, und Sie müssen sicherstellen, dass Sie nicht vergessen zu entfernen, bevor Sie Sie freigeben. Darüber hinaus werden Sie möglicherweise feststellen, dass Sie nicht entfernen können; vielleicht gibt es ein paar akzeptable verwendet, zum Beispiel in Test-code, der nicht an die Kunden ausgeliefert.

InformationsquelleAutor der Antwort oefe

Zwei Gründen:

1. Methoden Stub sind während der Entwicklung, und die Ausnahmen zu erinnern, die Entwickler, die Ihren code zu schreiben, ist noch nicht abgeschlossen.

2. Implementierung einer Unterklasse, die Schnittstelle, die durch design, nicht implementieren eine oder mehrere Methoden der geerbten Basisklasse oder Schnittstelle. (Einige Schnittstellen sind einfach zu allgemein.)

InformationsquelleAutor der Antwort David R Tribble

Müssen Sie diese Ausnahme für COM-interop. Es ist E_NOTIMPL. Der verlinkte blog zeigt auch andere Gründe

InformationsquelleAutor der Antwort MSalters

NotImplementedException

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

Macht dies eine einzige Ausnahme definiert .NET core macht es leichter zu finden und Sie auszulöschen. Wenn jeder Entwickler sollte erstellen Sie Ihre eigenen ACME.EmaNymton.NotImplementedException wäre es schwerer, Sie zu finden alle.

NotSupportedException

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

Zum Beispiel, wenn es ist ein Versuch, zu Lesen, zu suchen, oder Sie schreiben auf einen stream, unterstützt nicht die aufgerufene Funktionalität.

Beispielsweise generierte Iteratoren (mit yield Schlüsselwort) ist ein IEnumeratoraber die IEnumerator.Reset Methode wirft NotSupportedException.

InformationsquelleAutor der Antwort dalle

Ich kann nicht verbürgen für NotImplementedException (ich weitgehend einverstanden mit Ihrer Sicht), aber ich habe NotSupportedException ausgiebig in der core-Bibliothek, die wir bei der Arbeit verwenden. Die DatabaseController, zum Beispiel, können Sie eine Datenbank erstellen, die von beliebigen unterstützten Typs verwenden dann die DatabaseController Klasse während der rest Ihres Codes, ohne sich allzu sehr um die Art der Datenbank unter. Ziemlich grundlegendes Zeug, nicht wahr? Wo NotSupportedException kommt in handliches (und wo hätte ich meine eigene Implementierung, wenn man nicht bereits vorhanden ist) ist zwei hauptfällen:

1) die Migration einer Anwendung auf eine andere Datenbank
Es wird oft argumentiert, dies nur selten, wenn überhaupt, geschieht oder gebraucht wird. Bullsh*t ist. Mehr herausholen.

2) Gleiche Datenbank, verschiedene Treiber
Jüngstes Beispiel dafür war, als ein client, die nutzt eine Access-Anwendung unterstützt ein Upgrade von WinXP auf Win7 x64. Keine 64-bit-JET-Fahrer, die Ihre IT-Mann installiert die AccessDatabaseEngine statt. Wenn Sie unsere app abgestürzt, wir konnten einfach aus dem log sehen es war DB.Verbinden Absturz mit NotSupportedException - das waren wir schnell in der Lage, zu behandeln. Ein weiteres Aktuelles Beispiel war einer unserer Programmierer, versucht die Transaktionen auf eine Access-Datenbank. Selbst wenn Ihnen der Zugriff Transaktionen unterstützt, unsere Bibliothek nicht unterstützt Zugriff auf Transaktionen, die (aus Gründen, die außerhalb der Reichweite dieses Artikels). NotSupportedException, es ist Ihre Zeit zu glänzen!

3) Generische Funktionen
Ich kann nicht glauben, eine prägnante "aus der Praxis" - Beispiel hier, aber wenn Sie darüber nachdenken, so etwas wie eine Funktion, die fügt einen Anhang an eine E-Mail, die Sie wollen, dass es in der Lage sein zu nehmen, ein paar gemeinsame Dateien wie JPEGs, alles abgeleitet aus verschiedenen stream-Klassen, und fast alles hat ".ToString" - Methode. Für den letzten Teil, man kann sicherlich nicht jede mögliche Art, so dass Sie machen es zu generisch. Wenn ein Benutzer übergibt OurCrazyDataTypeForContainingProprietaryspreadsheetdata, reflektion verwenden, um test für das Vorhandensein von eine ToString-Methode und zurück NotSupportedException aus, um anzugeben, Mangel an Unterstützung für diese Datentypen nicht unterstützen ToString.

NotSupportedException nicht durch Mittel, die eine entscheidende Funktion, aber es ist etwas, ich finde mich viel mehr, wie ich die Arbeit an größeren Projekten.

InformationsquelleAutor der Antwort nathanchere

Selten ich nutze es für das interface reparieren. Angenommen, Sie haben eine Schnittstelle, die Sie erfüllen müssen aber bestimmte Methode wird nie aufgerufen, die von jedermann, also nur stick eine NotImplementedException und wenn jemand anruft, wird man Sie wissen, dass Sie etwas falsch machen.

InformationsquelleAutor der Antwort dr. evil

Sind Sie beide hacks für zwei gemeinsame Probleme.

NotImplementedException ist ein workaround für Entwickler, die Architektur-Astronauten und gerne schreiben Sie die erste API, code später. Offensichtlich, denn dies ist nicht ein inkrementeller Prozess, Sie können nicht alle auf einmal umzusetzen, und deshalb wollen Sie so tun, Sie sind semi-getan durch das werfen NotImplementedException.

NotSupportedException ist ein hack, um die Beschränkung der Art von Systemen, wie Sie in C# und Java. In diese Systeme, Sie sagen, dass Sie ein Rechteck "ist ein" Form der iff Rechteck erbt alle Formen Merkmale (inkl. member-Funktionen + Variablen). Doch in der Praxis ist dies nicht wahr. Zum Beispiel, ein Quadrat ist ein Rechteck, sondern ein Quadrat ist eine Einschränkung auf ein Rechteck, nicht eine Verallgemeinerung.

Also, wenn Sie wollen, um zu Erben, und beschränken das Verhalten der übergeordneten Klasse, Sie werfen NotSupported auf Methoden, die keinen Sinn für die Einschränkung.

InformationsquelleAutor der Antwort

Gut, ich eher Zustimmen. Wenn eine Schnittstelle wurde in einer solchen Weise, dass nicht alle Klassen implementieren können alle bits des es, es sollte haben wurde abgebaut, meine Meinung.

Wenn IList können oder können nicht geändert werden, es sollte haben wurde unterteilt in zwei, eine für die unveränderliche Teil (Getter, Suche, etc.), und eine für den modifizierbaren Teil (setter, hinzufügen, entfernen, etc.).

InformationsquelleAutor der Antwort Lasse Vågsæther Karlsen

Hier ist ein Beispiel: In Java, wenn Sie das interface implementieren Iterator Sie überschreiben müssen, die offensichtliche Methoden hasNext() und next()aber es gibt auch delete(). In 99% der usecases, die ich habe brauche ich nicht, also habe ich nur werfen eine NotImplementedException. Das ist viel besser als schweigend nichts tun.

InformationsquelleAutor der Antwort martinus

Wenn Sie nicht es verwenden möchten, dann ignorieren Sie es einfach. Wenn Sie einen code-block, dessen Erfolg hängt von jedem Stück, der es gelingt, aber es möglicherweise nicht dazwischen, dann ist Ihre einzige option ist, fangen die base Exception und roll zurück, was rückgängig gemacht werden soll. Vergessen NotImplementedException. Es könnten Tonnen von Ausnahmen, wie MyRandomException und GtfoException und OmgLolException. Nachdem Sie ursprünglich den code schreiben könnte ich komm vorbei und werfen eine exception-Typ aus der API, die Sie aufrufen. Eine, die nicht existieren, wenn Sie schrieb deinen code. Behandeln Sie die, die Sie wissen, wie zu handhaben und rollback für alle anderen, d.h., catch(Exception). Es ist ziemlich einfach, finde ich... ich finde es kommt auch praktisch. Vor allem, wenn Sie versuchen, ausgefallene Dinge mit der Sprache/framework, die gelegentlich zwingen, Dinge auf Sie.

Ein Beispiel, das ich habe, ist die Serialisierung. Ich habe Eigenschaften in mir an .NET-Bibliothek, die nicht in der Datenbank vorhanden sind (zum Beispiel, bequeme Wrapper über vorhandene "dumme" Eigenschaften, wie ein FullName Eigenschaft, kombiniert FirstNameMiddleNameund LastName). Dann möchte ich zu serialisieren, diese Datentypen auf XML senden Sie Sie über den Draht (z.B. von einem ASP.NET Anwendung von JavaScript), aber die Serialisierungs-framework nur serialisiert öffentliche Eigenschaften mit beiden get und set Accessoren. Ich will nicht, dass Sie in der Lage sein FullName weil dann müsste ich parse es aus und es könnte einige unvorhergesehene format, dass ich falsch analysieren und die Integrität der Daten geht aus dem Fenster. Es ist einfacher, nur die zugrunde liegenden Eigenschaften, aber da die Sprache und der API erfordern, die mich set accessor, werfe ich ein NotImplementedException (ich war nicht bewusst NotSupportedException bis ich diesen thread gelesen, aber entweder man arbeitet), so dass, wenn einige Programmierer, die Straße runter, nicht versuchen FullName er begegnen Ausnahme beim testen und erkennen, seinen Fehler.

InformationsquelleAutor der Antwort bambams