Nunit: Auslaufen der Guard-Klasse

Erstellt am 24. Sept. 2018  ·  4Kommentare  ·  Quelle: nunit/nunit

ReSharper und (in den letzten Jahren) Visual Studio schlagen vor, ArgumentNullException und ähnliche Argumentprüfungen einzufügen. Es ist ein solches Muskelgedächtnis, dass ich sie mehrmals versehentlich in die Codebasis eingeführt habe.

Direktes Werfen ist vom Standpunkt der Flusssteuerungsanalyse idiomatischeres C#. Der C#-Compiler versteht, dass Sie vor der Verwendung keinen Wert zurückgeben oder eine Variable initialisieren oder einen Schalterfall unterbrechen müssen, wenn Sie throw anstelle von Guard . Die Nullflussprüfung von ReSharper ist auf die gleiche Weise.

Mit C# 7.0 können Throw-Ausdrücke außerdem praktisch sein. Zum Beispiel die Syntax _foo = foo ?? throw new ArgumentNullException(nameof(Foo)); .

Was sind andere Vor- oder Nachteile, wenn wir es Mitwirkenden und uns selbst erlauben, Ausnahmen direkt auszulösen, anstatt Guard zu verwenden?

Hilfreichster Kommentar

Ich persönlich mag die Wachklasse - aber ich stimme zu, dass es ein Problem mit der Auffindbarkeit gibt. Normalerweise würde ich es regelmäßigen Mitwirkenden empfehlen, aber nicht einmaligen Mitwirkenden erwähnen. Ich glaube nicht, dass wir in diesem Bereich besonders Konstanz brauchen, oder? Ich freue mich, es zu sehen, wenn es da ist, aber keine Sorge, wenn es nicht da ist.

Ich bin dem Ausgang dieses Problems ziemlich apathisch, so oder so ist es für mich in Ordnung 😊

Alle 4 Kommentare

Der Hauptvorteil für die Verwendung der Klasse Guard ist die Benutzerfreundlichkeit, wenn ich mich richtig erinnere. In einer C#-fähigen IDE ist dies für mich oder neue Mitwirkende nicht mehr die einfachste Option. Brauchen wir Konsistenz, in die eine oder in die andere Richtung? Konsistenz stellt das, was für einige von uns am einfachsten ist, gegen das (potenziell) einfachste für andere von uns aus.

Ich persönlich mag die Wachklasse - aber ich stimme zu, dass es ein Problem mit der Auffindbarkeit gibt. Normalerweise würde ich es regelmäßigen Mitwirkenden empfehlen, aber nicht einmaligen Mitwirkenden erwähnen. Ich glaube nicht, dass wir in diesem Bereich besonders Konstanz brauchen, oder? Ich freue mich, es zu sehen, wenn es da ist, aber keine Sorge, wenn es nicht da ist.

Ich bin dem Ausgang dieses Problems ziemlich apathisch, so oder so ist es für mich in Ordnung 😊

Ich bin da auch etwas apathisch. Es bietet Konsistenz und korrekte Verwendung von Ausnahmekonstruktoren (ich habe die Nachricht und den Parameternamen ein paar Mal rückwärts gesehen), aber es fügt dem Callstack auch eine zusätzliche Methode hinzu. Außerdem macht es die neue C#-Syntax, wie Sie sagen, viel einfacher.

Ich bin mir nicht sicher, ob wir eine umfassende Säuberung brauchen, aber ich bin damit einverstanden, sie nicht zu fordern.

Danke an alle, hört sich gut an!

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen