Welchen Sinn hat diese Assert Zeile?

[Furtbichler]

Nennt sich übrigens 'fail fast'. Genauergesagt sind das ca. 5% von Fail fast und noch genauer ist das nur dann fail fast, wenn die Assertions mit kompiliert werden.
Das fail fast Paradigma sorgt dafür, das ein System zum frühestmöglichen Zeitpunkt meckert. Ohne das Assert/If würde die Klasse mit Sicherhiet auch irgendwo knallen, aber erst später.

Zu fail fast gehört u.a. auch, das ein Iterator (for in) meckert, wenn versucht wird, die Enumeration (aka die Liste) zu verändern, während man durch sie durch iteriert. Ich glaube, Delphi ist hier noch nicht so weit.

Ich musste mich auch daran gewöhnen. Macht den Code ein wenig unleserlicher, finde ich, aber wenn man es kennt, ist es wirklich ein Teil der Spezifikation/Dokumentation. In C# kann man das mit Attributen (Annotations) machen. Irgendwo gabs vor kurzem hier einen interessanten Thread darüber.

[Namenloser]

Assertions kann man wie so eine Art Pre- oder Post-Condition verwenden. Ich habe das z.B. letztens exzessiv eingesetzt, als ich (a,b)-Bäume implementiert habe. Und da ist es durchaus sinnvoll, wenn der Assert-Code nicht in der Release-Fassung landet, weil einige der Prüfungen, ob der Baum gültig ist, recht kompliziert sind, sodass die Laufzeitgarantien mit dem Assertion-Code nicht eingehalten werden würden.

Exceptions sollte man an Stellen einsetzen, wo der Fehler durch falsche Benutzung wirklich ausgelöst werden könnte. Assertions kann man dagegen in Fällen einsetzen, die theoretisch gar nicht auftreten sollten.

Z.B. beim (a,b)-Baum sollte es ja theoretisch nie passieren, dass Invarianten des Baumes kaputt gehen, egal was der Benutzer damit anstellt. Aber bei der Entwicklung macht man immer erst mal was falsch und da hilft sowas beim Debuggen enorm. Wenn man Ende dann alles läuft, könnte man den Assertion-Code natürlich prinzipiell wieder rauslöschen, aber wenn man ihn schon mal hat, ist es doch besser, ihn gleich drinzulassen, denn das hilft ja auch dem menschlichen Leser.

[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.