Warum werden Assertions aus den Produktions-Builds herauskompiliert (abgesehen von der Leistung)?

Question

Das typische Argument für die Entfernung von Assertions aus Produktionscode ist die Leistung. Das leuchtet mir nicht ein. Ja, es kann eine nützliche Optimierung sein, ein paar Assertions aus den leistungsrelevanten 5 % oder so Ihres Codes zu entfernen. Für die anderen 95 % haben sie jedoch wahrscheinlich keinen messbaren Effekt, und Assertions können nur die Wahrscheinlichkeit erhöhen, dass Ihr Code im Falle eines Fehlers schnell und einfach zu diagnostizieren ist.

Ich programmiere die meiste Zeit in D, das über eine enforce() Funktion, die im Wesentlichen das tut, was assert() mit der Ausnahme, dass es in Release-Builds bleibt. Normalerweise verwende ich enforce() die meiste Zeit, und assert() nur an einigen wenigen Orten, wo enforce() wäre zu teuer.

Gibt es neben der Leistung noch einen anderen Grund, Asserts aus Release-Builds zu entfernen? Wenn nicht, warum machen Sprachen das Standardverhalten von Asserts nicht so, dass sie immer ausgeführt werden, auch in Release-Builds, und bieten eine zweite Funktion an, die ausführlicher und schwerer zu merken ist, etwas wie expensiveAssert() die aus Release-Builds herausgenommen wird, und empfehlen Sie, sie nur in leistungskritischen Teilen Ihres Codes zu verwenden?

Answer 1

Ich denke assert() war in erster Linie als reines Entwicklerwerkzeug gedacht.

Eine Software für Endbenutzer sollte eine Art von Fehlerbehandlung bieten (durch Protokollierung und/oder Anzeige einer Meldung an den Benutzer). assert() bietet keine Fehlerbehandlung.

In der Regel verwende ich jedoch meine eigenen Release- und Debug-Assert-Funktionen. Sowohl release als auch debug assert werden nur bei ungewöhnlichen Fehlern verwendet - die nie auftreten sollten. Aber sie geben eine nützliche Fehlermeldung aus (nützlich für den Entwickler, normalerweise nicht so hilfreich für den Endbenutzer).

Eventuell auftretende Fehler (Eingabe/Ausgabe, Fehlkonfiguration, ) werden explizit behandelt und dem Benutzer gemeldet.

Answer 2

Es ist nicht nur das. Ich denke, dass die Beibehaltung von Assertions in Produktions-Builds die Paranoia der Leute darüber verstärken würde, welcher Text (und/oder Quellcode-Schnipsel) in ausgelieferten Binärdateien landet (stellen Sie sich vor, wie Code-Kommentare aussehen würden, wenn sie in ausgelieferten Binärdateien landen würden!), was wiederum von der Verwendung von Assertions abhalten würde.

Ihre Erfahrungen können variieren.

Answer 3

Meine Antwort wäre, dass Behauptungen die Ausführung des Programms vorzeitig abbrechen, oft dann, wenn es nicht notwendig ist. Obwohl man paranoid sein könnte, weil eine übersprungene Assertion zu einem unbestimmten Verhalten führt, kann das Programm trotzdem weiterlaufen. Assertions können wirklich lästig und dumm sein, wenn man als Benutzer auf sie stößt. Zum Beispiel: Warum kann dieses Spiel nicht mit EINER ungültigen Textur umgehen?!

Obwohl Assertions eine großartige Möglichkeit sind, Fehler bei der Entwicklung schnell zu erkennen, hassen sie die Benutzer (meiner Meinung nach).

Answer 4

Ich denke, assertions im produktionscode zu haben ist OK. sie zu deaktivieren führt dazu, dass man einige einblicke in die probleme des systems in der produktion verliert. und ich bin immer daran interessiert, wie sich mein programm/system in der produktion verhält und versagt. meiner meinung nach kommen die besten "testdaten" zur verbesserung ihres systems oft von echten benutzern.

was ich bevorzuge:

• Behauptungen im Produktionscode beibehalten
• Protokoll mit guten Informationen für den Fall, dass Assert fehlschlägt
• den Assertion-Fehler behandeln (->niemals dem Benutzer einen Stack-Trace zeigen)
• nach einer Weile die Protokolldateien auf Assert-Fehler überprüfen und den Code korrigieren (für mich sind Assertions Programmier- oder Vertragsverletzungs-Fehlerauslöser)