Warum sollte ich Asserts verwenden?

Ich bin nie auf die Idee von Asserts gekommen – warum sollte man sie jemals verwenden?

Ich meine, sagen wir, ich wäre ein Formelfahrer und alle Asserts waren Dinge wie Sicherheitsgurt, Helm usw.

Die Tests (im Debug) waren alle in Ordnung, aber jetzt wollen wir Rennen fahren (Release)! Sollten wir alle Sicherheitsvorkehrungen fallen lassen, weil es beim Testen keine Probleme gab?

Ich werde sie niemals entfernen. Ich denke, die meisten Leute, die behaupten, dass das Entfernen von etwas, das mit Asserts vergleichbar ist, nie ihren Code profiliert haben oder die Asserts absolut verschoben wurden. Ich habe noch nie einen wirklichen Leistungsvorteil gesehen, insbesondere in Bezug auf die 80/20-Regel.

Also, verfehle ich irgendwie den Punkt, oder könnte mir jemand sagen, warum ich Asserts verwenden sollte? Übrigens verwende ich Unit-Tests.

Erstens der Leistungsunterschied kann riesig sein. In einem Projekt verursachten unsere Behauptungen buchstäblich eine 3-fache Verlangsamung. Aber sie haben uns geholfen, einige wirklich lästige Fehler aufzudecken.

Genau das ist der Punkt.

Asserts sind da, um Ihnen zu helfen, Fehler zu finden. Und Weil Da sie in Release-Builds entfernt werden, können wir es uns leisten, viele davon einzubauen, ohne uns Gedanken über die Leistung machen zu müssen. Wenn Sie nicht da sind, um auf fehlgeschlagene Behauptungen tatsächlich zu reagieren, werden sie wertlos, also können wir sie genauso gut entfernen.

Auch das Abfangen des Fehlers und das Auslösen einer Ausnahme ist keine wirkliche Lösung. Die Programmlogik ist fehlerhaft, und selbst wenn wir die Ausnahme behandeln, ist das Programm immer noch kaputt.

Was Behauptungen im Grunde darauf hinauslaufen, ist “Warum sollten Sie sich die Mühe machen, Fehler abzufangen, mit denen Sie nicht umgehen können?”

Einige Fehler müssen während der Entwicklung abgefangen werden. Wenn sie über das Testen hinaus in den von einem Kunden verwendeten Release-Build schlüpfen, ist das Programm einfach kaputt, und keine noch so große Laufzeitfehlerprüfung wird es beheben.

Ich bin nie auf die Idee von Asserts gekommen – warum sollte man sie jemals verwenden?

Ich meine, sagen wir, ich wäre ein Formelfahrer und alle Asserts waren Dinge wie Sicherheitsgurt, Helm usw.

Ja, das ist ein gutes Beispiel dafür, wann nicht ein Assertion verwenden. Dies sind Dinge, die zur Laufzeit tatsächlich schief gehen können und die überprüft werden müssen. Ihr Formel-1-Fahrer könnte einige Sicherheitsvorkehrungen vergessen, und wenn er dies tut, wollen wir die ganze Sache stoppen, bevor jemand verletzt wird.

Aber was ist mit der Prüfung, ob der Motor eingebaut ist? Müssen wir das überprüfen während des Rennens?

Natürlich nicht. Wenn wir ohne Motor ins Rennen gehen, sind wir am Arsch, und selbst wenn wir den Fehler entdecken, ist es zu spät, etwas dagegen zu unternehmen.

Stattdessen ist dies ein Fehler, der während der Entwicklung abgefangen werden muss oder gar nicht. Wenn die Designer vergessen, einen Motor in ihr Auto einzubauen, müssen sie diesen Fehler während der Entwicklung erkennen. Das ist eine Behauptung. Es ist für die Entwickler während der Entwicklung relevant, aber danach darf der Fehler nicht mehr vorhanden sein, und wenn doch, können wir nichts tun.

Das ist im Grunde der Unterschied. Eine Ausnahme soll dem Benutzer helfen, Fehler zu behandeln, die behandelt werden können.

Ein Assertion ist da, um zu helfen Sieindem Sie auf Fehler aufmerksam gemacht werden, die gar nicht erst auftreten dürfen und vor dem Produkt behoben werden müssen kann versendet werden. Fehler, die nicht von Benutzereingaben abhängen, sondern davon, dass Ihr Code das tut, was er tun soll.

Die Quadratwurzel aus vier muss noch nie auf drei auswerten. Der Fehler ist einfach unmöglich. Wenn es auftritt, ist Ihre Programmlogik einfach kaputt. Es spielt keine Rolle, wie viel Fehlerbehandlung wir darum wickeln, es ist etwas, das während der Entwicklung abgefangen werden muss oder überhaupt nicht. Wenn wir die Ausnahmebehandlung verwenden, um nach diesem Fehler zu suchen und ihn zu behandeln, was wird die Ausnahme tun? Sagen Sie dem Benutzer: “Das Programm ist grundlegend kaputt. Verwenden Sie es niemals”?

Eine E-Mail des Entwicklers hätte das erreichen können. Warum sollte man es in den Programmcode einbauen? Das ist ein Beispiel für ein Problem, das einfach nicht auftreten darf. Wenn ja, müssen wir zurückgehen und das Programm reparieren. Eine andere Form der Fehlerbehandlung ist nicht möglich.

Einige Fehler, wie z. B. das Öffnen einer Datei zum Lesen, sind jedoch vorhanden möglich. Auch wenn es schlimm sein kann, wenn es passiert, müssen wir es akzeptieren kann passieren. Also müssen wir damit umgehen, wenn es so ist.

Asserts dienen dazu, die Fehler abzufangen, die unmöglich passieren können.

Andrew Koenig hatte früher eine gute philosophische Diskussion über die Verwendung von Ausnahmen und Behauptungen im Versandkodex. Schlussendlich, Sie hüten sich davor, wilde Dinge zu tun, wenn das Programm in einem irreparabel kaputten Zustand ist.

Ich glaube daher, dass es besser ist, wenn ein Programm etwas entdeckt, das mit seinem internen Zustand unwiderlegbar falsch ist, es sofort zu beenden, anstatt seinem Aufrufer die Gelegenheit zu geben, so zu tun, als wäre nichts falsch.

Wenn Sie möchten, denke ich, dass Ausnahmen für Situationen reserviert sein sollten, in denen es möglich ist, nach dem Abfangen der Ausnahme etwas Vernünftiges zu tun. Wenn Sie einen Zustand entdecken, den Sie für unmöglich hielten, ist es schwer, viel darüber zu sagen, was danach passieren könnte.

Aus Code Complete 2: „Verwenden Sie die Fehlerbehandlung für Bedingungen, von denen Sie erwarten, dass sie eintreten; verwenden Sie Zusicherungen für Bedingungen, die niemals eintreten sollten.“

Ein häufig zitiertes Beispiel ist die Prüfung auf Null im Nenner vor einer Division.

Es wird erwartet, dass Sie die Behauptungen aus dem Produktionscode entfernen. Sie sind während der Entwicklung vorhanden, um Ihnen zu helfen, Fehler zu erkennen.

Unit-Tests sind kein Ersatz für Behauptungen.

Weil sie das Debuggen erleichtern.

Der zeitaufwändige Teil des Debuggens besteht darin, ein Problem von dem Symptom, das Sie zuerst bemerken, bis zum Fehler im Code zurückzuverfolgen. Gut geschriebene Behauptungen lassen das Symptom, das Sie bemerken, viel näher an das eigentliche Codeproblem heranrücken.

Ein sehr einfaches Beispiel wäre ein Fehler, bei dem Sie über das Ende eines Arrays hinaus indizieren und eine Speicherbeschädigung verursachen, die schließlich einen Absturz verursacht. Es kann lange dauern, vom Absturz bis zur betreffenden Indexoperation zurückzuverfolgen. Wenn Sie jedoch neben dieser Indexoperation eine Assertion haben, die Ihren Index überprüft, schlägt Ihr Programm direkt neben dem Fehler fehl, sodass Sie das Problem schnell finden können.

Es ist ein umstrittenes Thema. Viele Leute, wie ich, ziehen es tatsächlich vor, sie im Produktionscode aktiviert zu lassen. Wenn Ihr Programm sowieso ins Unkraut gerät, können Sie die Assertion genauso gut darin haben, damit Ihr Kunde Ihnen zumindest die Zeilennummer und den Dateinamen geben kann (oder welche Informationen oder Aktionen Sie auch immer für die Assertion konfigurieren). Wenn Sie die Behauptung weggelassen haben, konnte der Kunde Ihnen nur sagen: „Es ist abgestürzt“.

Das bedeutet, dass Sie wahrscheinlich keine teuren Operationen in Ihren Assert-Prüfungen durchführen oder zumindest profilieren sollten, um zu sehen, ob sie Leistungsprobleme verursachen werden.

Sie ermöglichen es Ihnen, Ihre Annahmen zu testen. Angenommen, Sie möchten die Geschwindigkeit berechnen. Sie möchten wahrscheinlich behaupten, dass Ihre Berechnung weniger als die Lichtgeschwindigkeit ist.

Behauptungen sind für die Entwicklung, um sicherzustellen, dass Sie nichts vermasseln.

Aus Ihrem Beitrag geht hervor, dass Sie der Idee, Assertionen zu verwenden, nicht widersprechen, sondern eher der Idee, Assertionen im Debug zu haben und sie nicht in der Produktion aktiv zu haben.

Der Grund dafür ist, dass Sie beim Debuggen möglicherweise möchten, dass der Prozess katastrophal fehlschlägt – dh eine Ausnahme auslöst und beendet wird, damit der Fehler behoben werden kann. In der Produktion könnte sich dies auf Ihr gesamtes System auswirken, und die Fehlerbedingung könnte nur in sehr wenigen Fällen auftreten. In der Produktion möchten Sie also wahrscheinlich den Fehler protokollieren, aber den Prozess am Laufen halten.

Mithilfe von Zusicherungen können Sie das Verhalten zwischen Debug und Release ändern.

Ich stimme Ihnen zu, dass die Zusicherungen nicht nur im Produktionscode zum Schweigen gebracht werden sollten – viele Fehler werden in Testumgebungen nicht aufgedeckt, und es ist wichtig zu wissen, wann Zusicherungen in der Produktion fehlschlagen.