In Java werde ich gelegentlich ein AssertionError werfen direkt, um zu bestätigen, dass eine bestimmte Linie nicht erreicht wird. Ein Beispiel dafür wäre, dass der default -Fall in einer switch -Anweisung nicht erreicht werden kann (siehe diese JavaSpecialists-Seite) für ein Beispiel).
Ich würde gerne einen ähnlichen Mechanismus in .Net verwenden. Gibt es eine äquivalente Ausnahme, die ich verwenden könnte? Oder gibt es eine andere Methode, die mit dem gleichen Effekt verwendet werden könnte?
Bearbeiten - Um dies zu verdeutlichen, suche ich nach einem Mechanismus, mit dem Fehler zur Laufzeit im freigegebenen Code markiert werden können, um anzuzeigen, dass eine Invariante im Code (möglicherweise katastrophal) ausgefallen ist . Das verknüpfte Beispiel generiert eine zufällige ganze Zahl zwischen 0 und 2 (einschließlich) und bestätigt, dass die generierte Zahl immer 0, 1 oder 2 ist. Wenn diese Behauptung nicht gilt, wäre es besser, die Ausführung vollständig zu stoppen, statt mit einer unbekannten fortzufahren korrupter Zustand des Systems.
Ich würde normalerweise InvalidOperationException oder ArgumentOutOfRangeException ausgeben, abhängig davon, woher der Wert kam.
Alternativ gibt es Debug.Assert (was nur dann fehlschlägt, wenn Sie das DEBUG-Präprozessorsymbol definiert haben) oder in .NET 4.0 könnten Sie abhängig von der Situation Contract.Fail , Contract.Assert oder Contract.Assume verwenden. Das explizite Auslösen einer Ausnahme hat den Vorteil, dass der Compiler weiß, dass die nächste Anweisung nicht erreichbar ist.
Ich bin kein großer Fan von Debug.Assert - normalerweise ist es für eine Veröffentlichung ungeeignet (da es eine Assertion-Box erzeugt und nicht nur versagt) und standardmäßig wird es in der Veröffentlichung sowieso nicht ausgelöst. Ich bevorzuge Ausnahmen, die immer geworfen werden, da sie verhindern, dass Ihr Code weiterläuft, auch wenn Sie feststellen müssen, dass "das Zeug falsch ist".
Code Contracts ändert das Spiel etwas, da es alle möglichen Optionen gibt, was zur Ausführungszeit erhalten bleibt, und der statische Checker kann helfen, zu beweisen, dass Sie nicht in diesen Zustand gelangen. Sie müssen jedoch noch die Ausführungszeit-Richtlinie auswählen ...
Sie können die Methode Trace.Assert verwenden, die bei Release-Builds funktioniert (wenn Sie haben das Kompilierungssymbol% co_de% definiert, das standardmäßig für Visual Studio-Projekte definiert ist. Sie können auch die Reaktion Ihrer Anwendung auf Assertionsfehler mithilfe einer TRACE anpassen. Der Standardwert ist (nicht überraschend) TraceListener , wodurch die Assertion in einem Dialogfeld angezeigt wird, wenn die Anwendung im interaktiven Modus ausgeführt wird. Wenn Sie beispielsweise eine Ausnahme auslösen möchten, können Sie Ihre eigene DefaultTraceListener erstellen und sie auf die Methode TraceListener . Sie können dann das Fail entfernen und Ihr eigenes, entweder programmgesteuert verwenden > oder in der Konfigurationsdatei .
Das sieht nach einer Menge Probleme aus und ist nur dann zu rechtfertigen, wenn Sie die Art und Weise, wie Ihre Anwendung Assertionen über die Trace-Listener behandelt, dynamisch ändern wollen. Erstellen Sie für Verletzungen, die immer fehlschlagen sollen, Ihre eigene DefaultTraceListener -Klasse und werfen Sie sie sofort weg.
Für .NET 4.0 würde ich definitiv auf die AssertionException Methode. Diese Methode wird jedoch nur dann kompiliert, wenn die Symbole Contract.Assert oder DEBUG definiert sind. CONTRACTS_FULL funktioniert nicht bei Release-Builds, und DEBUG schaltet auch alle anderen Verträge ein, die überprüft werden, von denen einige nicht in Release-Builds vorhanden sein sollten.
Tags und Links java .net exception assertions