Validierung von Funktionsargumenten?

Question

Ich validiere regelmäßig meine Funktionsargumente:

public static void Function(int i, string s)
{
  Debug.Assert(i > 0);
  Debug.Assert(s != null);
  Debug.Assert(s.length > 0);
}

Natürlich sind die Prüfungen im Rahmen der Funktion "gültig".

Ist dies branchenüblich? Was ist die gängige Praxis bei der Validierung von Funktionsargumenten?

Answer 1

Die akzeptierte Praxis ist wie folgt, wenn die Werte nicht gültig sind oder zu einem späteren Zeitpunkt eine Ausnahme verursachen:

if( i < 0 )
   throw new ArgumentOutOfRangeException("i", "parameter i must be greater than 0");

if( string.IsNullOrEmpty(s) )
   throw new ArgumentNullException("s","the paramater s needs to be set ...");

Die Liste der grundsätzlichen Ausnahmen von Argumenten lautet also wie folgt:

ArgumentException
ArgumentNullException
ArgumentOutOfRangeException

Answer 2

Was Sie geschrieben haben, sind Vorbedingungen und ein wesentliches Element der Vertragsmäßiges Design . Googeln Sie (oder "StackOverflow":) nach diesem Begriff und Sie werden eine Menge guter Informationen darüber finden, aber auch einige schlechte. Beachten Sie, dass die Methode auch Folgendes umfasst Nachkonditionen und das Konzept der Klasseninvariante .

Wir sollten uns darüber im Klaren sein, dass Behauptungen ein gültiger Mechanismus sind.

Natürlich sind sie normalerweise ( nicht immer ) pas im Freigabemodus aktiviert ist. Das bedeutet, dass Sie Ihren Code vor der Freigabe testen müssen.

Wenn Assertions aktiviert bleiben und eine Assertion verletzt wird, besteht das Standardverhalten in einigen Sprachen, die Assertions verwenden (und insbesondere in Eiffel) darin, eine Assertion Violation Exception zu werfen.

Ungeprüfte Behauptungen sind pas ein bequemer oder ratsamer Mechanismus, wenn Sie eine Code-Bibliothek veröffentlichen, noch (natürlich) eine Möglichkeit, direkte, möglicherweise falsche Eingaben zu überprüfen. Wenn Sie "möglicherweise falsche Eingaben" haben, müssen Sie als Teil des normalen Verhaltens Ihres Programms eine Eingabeüberprüfung vorsehen Ebene ; aber Sie können trotzdem Assertions in den internen Modulen frei verwenden.

---

Andere Sprachen, wie Java, haben eher eine Tradition der explizite Überprüfung der Argumente und Auslösen von Ausnahmen, wenn sie falsch sind hauptsächlich deshalb, weil diese Sprachen keine starke "assert"- oder "design by contract"-Tradition haben.

(Es mag manchen seltsam erscheinen, aber ich finde die Unterschiede in der Tradition respektabel und nicht unbedingt schlecht).

Siehe auch diese verwandte Frage .

Answer 3

Sie sollten keine Asserts verwenden, um Daten in einer laufenden Anwendung zu validieren. Nach meinem Verständnis sind Asserts dazu gedacht, zu testen, ob die Funktion auf die richtige Weise verwendet wird. Oder ob die Funktion den richtigen Wert zurückgibt, d.h. ob der Wert, den Sie erhalten, dem entspricht, was Sie erwartet haben. Sie werden häufig in Test-Frameworks verwendet. Sie sollten ausgeschaltet werden, wenn das System bereitgestellt wird, da sie langsam sind. Wenn Sie ungültige Fälle behandeln möchten, sollten Sie dies explizit tun, wie der obige Beitrag erwähnte.

Answer 4

Jeder Code, der über das Netzwerk oder über die Kommunikation zwischen Prozessen aufgerufen werden kann, muss unbedingt eine Parametervalidierung haben, da es sich sonst um eine Sicherheitslücke handelt - aber Sie müssen eine Ausnahme auslösen, was Debug.Assert nicht tut, da es nur Debug-Builds überprüft.

Jeder Code, den andere Leute in Ihrem Team verwenden, sollte auch Parameter-Validierungen haben, nur weil es ihnen helfen wird, zu wissen, dass es ihr Fehler ist, wenn sie Ihnen einen ungültigen Wert übergeben, auch dieses Mal sollten Sie Ausnahmen auslösen, weil Sie eine nette Beschreibung einer Ausnahme mit Erklärung hinzufügen können, was sie falsch gemacht haben und wie man es beheben kann.

Debug.Assert in Ihrer Funktion ist nur dazu da, Ihnen bei der Fehlersuche zu helfen, es ist eine nette erste Verteidigungslinie, aber es ist keine "echte" Validierung.

Answer 5

Pour öffentlich Funktionen, insbesondere API-Aufrufe, sollten Sie Ausnahmen auslösen. Die Verbraucher würden es wahrscheinlich zu schätzen wissen, wenn sie wüssten, dass ein Fehler in ihrem Code vorliegt, und eine Ausnahme ist der garantierte Weg, dies zu tun.

Für interne oder private Funktionen ist Debug.Assert in Ordnung (aber nicht notwendig, IMO). Sie nehmen keine unbekannten Parameter auf, und Ihre Tests sollten alle ungültigen Werte durch die erwartete Ausgabe auffangen. Aber manchmal können Sie mit Debug.Assert einen Fehler viel schneller aufspüren oder verhindern.

Bei öffentlichen Funktionen, die keine API-Aufrufe sind, oder bei internen Methoden, die von anderen Personen aufgerufen werden können, können Sie sich für einen der beiden Wege entscheiden. Ich bevorzuge im Allgemeinen Ausnahmen für öffentliche Methoden und lasse interne Methoden (normalerweise) ohne Ausnahmen auskommen. Wenn eine interne Methode besonders anfällig für Missbrauch ist, dann ist eine Ausnahme gerechtfertigt.

Sie wollen zwar Argumente validieren, aber Sie wollen keine 4 Validierungsebenen, die Sie synchron halten müssen (und für die Sie einen Strafzuschlag zahlen). Validieren Sie also an der externen Schnittstelle und vertrauen Sie einfach darauf, dass Sie und Ihre Mitarbeiter in der Lage sind, die Funktionen entsprechend aufzurufen und/oder den Fehler zu beheben, der unweigerlich entsteht.