Sollte ich CA1062 unterdrücken: Argumente der öffentlichen Methoden validieren?

Question

Ich habe mein Projekt kürzlich von Visual Studio 2008 auf Visual Studio 2010 aktualisiert.

In Visual Studio 2008 ist diese Regel für die Codeanalyse nicht vorhanden.

Jetzt bin ich mir nicht sicher, ob ich diese Regel verwenden soll oder nicht.

Ich baue eine Open-Source-Bibliothek, so dass es wichtig scheint, die Leute davor zu bewahren, Fehler zu machen. Wenn ich aber nur ArgumentNullException mit dem Parameter null wähle, scheint es, als würde ich nutzlosen Code schreiben, da ArgumentNullException geworfen wird, auch wenn ich diesen Code nicht schreiben werde.

EDIT: Auch gibt es ein Leistungsproblem, das angesprochen werden muss. Die Überprüfung auf null in jeder öffentlichen Methode kann zu Leistungsproblemen führen.

Sollte ich diese Regel entfernen oder die Verstöße beheben?

Answer 1

Das hängt davon ab. Die Konvention bei der Verwendung von ArgumentNullException besteht darin, den Namen des Nullarguments in die Beschreibung aufzunehmen. Der Anrufer wird also genau wissen, was schief gelaufen ist.

Die Quelle einer NullReferenceException (was passiert, wenn Sie nicht validieren) kann leicht zu erkennen sein, aber wenn die Methode komplex ist, kann es schwieriger sein. Möglicherweise landen Sie in einer Codezeile, in der mehrere Referenzen null sein können.

Persönlich bevorzuge ich öffentliche Methoden ArgumentNullException zu werfen, wenn sie keine Nulleingabe für das gegebene Argument behandeln können, weil es ein konsistentes Verhalten ermöglicht, egal wie die Methode implementiert wird.

Als Antwort auf die Bearbeitung: Meiner Meinung nach ist es wichtiger, eine einheitliche Reihe von Schnittstellen mit einigen Überraschungen als die Optimierung jeder Codezeile zu bieten. Meine Vermutung ist, dass in den meisten Fällen der Leistungsaufwand des Null-Checks nicht signifikant ist. Wenn sich herausstellt, dass es sich um ein Problem handelt (wie es im Profiling so heißt), würde ich darüber nachdenken, es zu ändern. Ansonsten würde ich es zu diesem Zeitpunkt nicht als Problem betrachten.

Answer 2

Wir behalten diese Regel, weil wir entschieden haben, dass es immer am besten ist, die Parameter bei ihrem ersten Eintrag in Ihren Code zu überprüfen. Wenn die Person, die Ihren Code verwendet, die Ausnahme erhält, ist der Kontext darin besser. Jemand, der zum Beispiel nicht über Ihren Quellcode verfügt, wird feststellen, dass die Ausnahme in Ihrem Code enthalten war, und könnte einen Fehlerbericht gegen Sie einreichen, weil er Ihre Zeit verschwendet.

Answer 3

IMHO Nein. Das Überprüfen auf Nullen ist fast nie der Leistungsengpass in Ihrer Anwendung. (Und in dem einen Fall, in dem es signifikant ist, wirst du es mit deinem Profiler finden und den einen Fall entfernen).

Die andere Frage, die sich in Ihrem Kopf bilden sollte, ist "ist neue NullReferenceException() werfen wirklich der beste Weg, um den Fehler zu behandeln?" Oft können Sie die Dinge besser handhaben (auch wenn Sie nur einen besseren Fehlerbericht für den Benutzer und/oder sich selbst zum Debuggen bereitstellen). In vielen Fällen kann Code mit Nullen umgehen, was es unnötig macht, dass dies ein Fehler ist.

bearbeiten

Ihre bearbeiten zu beantworten: Null Kontrollen lange nicht wirklich nehmen. Der Aufwand für das einfache Aufrufen einer Methode beträgt zehn, wenn nicht hundertmal mehr als eine Nullprüfung.Der einzige Ort, an dem ein Null-Check einen signifikanten Unterschied macht, ist eine große, enge Schleife, in der Sie sehr wenig tun. Diese Situation passiert nicht sehr oft - normalerweise werden Sie nach einer Null suchen und dann etwas relativ teuer mit dieser Referenz tun.

Es gibt keine Situation, in der ein Crash oder Fehler eine gute Sache ist. Es ist immer besser, die Anwendung mit Null-Checks zu "verlangsamen", als zu stürzen und die Daten Ihres Kunden zu verlieren.

Also optimieren Sie Ihren Code nicht vorzeitig. Schreiben Sie es gut, um wartbar und robust zu sein, dann Profil es zu sehen, wo die Engpässe sind. Ich programmiere seit 28 Jahren, bin sehr liberal mit Null-Checks und habe nie festgestellt, dass ein Null-Check die Ursache für ein Performance-Problem war. Normalerweise sind es Dinge wie unnötige Arbeit in einer Schleife, mit einem O (n^3) -Algorithmus, wo ein O (n^2) Ansatz möglich ist, teure rechenwerte zu cachen usw.