Welchen Sinn hat diese Assert Zeile?

[Der schöne Günther]

Aber ist das nicht eher ein Fall für Unit-Tests? Wenn ich (berechtigterweise) Angst hätte, durch laufende Arbeiten am Code seine (oder davon abhängige) Funktionsweisen ungewollt und unbewusst zu beinflussen sind das doch klassische Kandidaten für Tests?

Wenn ich mich nicht täusche, dann stoppt der Debugger bei einer fehlgeschlagenen Assertion durch die im Endeffekt geworfene EAssertionFailed dazu noch erstmal ganz woanders.

Wahrscheinlich ist es auch zu einem guten Teil Glaubens- und Geschmackssache, aber in meinem ganz persönlichen "Exception werfen vs. Assertion scheitern lassen"-Konflikt stehe ich mit dem Banner in der Hand klar auf der Seite der ganz normalen Exceptions. Die sowohl in Debug-, als auch Releasefassung geworfen werden.

[Namenloser]

Unit-Tests und Assertions ergänzen sich meiner Meinung nach. Wenn ich beispielsweise so einen Baum teste, dann sagt der Unit-Test mir zwar, dass was schiefgelaufen ist, aber nicht wo. Und genau da helfen dann die Assertions.

[jaenicke]

@Günther: Mit Unittests kannst du aber die Interna einer Klasse und deren Methoden nicht sinnvoll überwachen und dazu sind sie auch nicht da.

Assertions prüfen bei der Entwicklung die Einhaltung bestimmter Bedingungen, auch ggf. mit größeren Kosten an Rechnerleistung, was aber egal ist, da sie im Release nicht enthalten sind.
Wenn du an der Stelle stattdessen die Prüfungen immer durchführst, auch im Release, ist die Performance ggf. richtig im Keller.

Unittests, Assertions und Exceptions dienen schlicht teilweise anderen Zielen, haben unterschiedliche Nebeneffekte und sind daher nicht überall sinnvoll gegeneinander austauschbar.

[Popov]

Danke für die Antworten. Es ist also so wie ich es mir gedacht habe - eine sinnvolle Zeile an sich, wenn aber einer im Internet in einem Standardbeispiel diese Zeile ganz am Anfang als erstes in einer Funktion eingebaut hat, dann ist es etwas übertrieben.

[Furtbichler]

Zitat von Popov:

wenn aber einer im Internet in einem Standardbeispiel diese Zeile ganz am Anfang als erstes in einer Funktion eingebaut hat, dann ist es etwas übertrieben.

Jain, er implementiert 'fail fast' und sagt im Standardbeispiel, das der Parameter nicht nil sein soll, ohne das in einem Kommentar so zu schreiben. Ist das übertrieben oder eine Angewohnheit?

[hoika]

Hallo,

schon diese Diskussion, die hoffentlich auch Delphi-Neulinge lesen,
zeigt mir, dass solch eine Zeile in einem "Standard-Beispiel" gut ist ...

Übrigens ist die Delphi-IDE selbst mit Asserts übersetzt,
Soviel zum Thema "Nicht in der Release-Version" verwenden.


Heiko

[Popov]

Zitat von Furtbichler:

...und sagt im Standardbeispiel, das der Parameter nicht nil sein soll

Ok, das ein Objekt nicht nil sein darf, ist ja nicht ungewöhnlich. Es gibt viele Funktionen in denen nach nil abgefragt wird, um dann dementsprechend zu reagieren, z. B. raus aus der Funktion oder Objekt erstellen oder oder... Aber das ist ja was anderes.

[Furtbichler]

Es wird zum frühestmöglichen Zeitpunkt sichergestellt, das die Methode ordnungsgemäß verwendet wird. Nicht der Folgefehler (durch Aufruf mit einem Nil-Objekt) ist das Problem/die Exception, sondern der Aufruf.

Zitat von hoika:

Übrigens ist die Delphi-IDE selbst mit Asserts übersetzt,
Soviel zum Thema "Nicht in der Release-Version" verwenden.

Wer sagt denn, das das aktuelle Delphi die 'Release'-Version ist? Im Release-Code wird das Assert nicht benötigt, denn im Code wird der Aufruf mit Nil ja erfolgeich durch Unit-Tests geprüft Wenn Emba Delphi mit Assertions ausliefert, spricht das doch sehr für die 'Qualität' und gegen Unittests.

In sicherheitsrelevantem Code (Flugzeug, Fahrzeugsteuerung etc.) bleiben Asserts erhalten bzw. werden durch 'echte' Abfragen ersetzt. Weil das zum 'fail fast' Paradigma gehört und dieser Code ruhig mit Hosenträgern, Gürteln und zusätzlichem Festtackern abgesichert sein soll.