Welchen Sinn hat diese Assert Zeile?

[Popov]

Ich sehe gelegentlich im Internet in fremden Prozeduren gleich am Anfang eine Assert Zeile. Das sieht in etwa so aus wie hier im Beispiel:

Delphi-Quellcode:

procedure Beispiel(Font: TFont);
begin
  Assert(Assigned(Font));
  ...

Was Assert macht ist mir klar, auch was Assigned macht. Somit ist mir durchaus klar was die Zeile bewirkt, bzw. bewirken könnte. Ist das Objekt hier nil, gibt es eine Fehlermeldung.

Was ich aber nicht erkenne ist der Sinn dahinter. Ich kenne etwa eine halbe Million Prozeduren in denen Objekte per Parameter übergeben werden und sie kommen ohne diese Zeile aus. Es kann schon mal vorkommen, dass ein Objekt nil ist. Dann gibt es eine Fehlermeldung (auch ohne Assert), dann sucht man den Fehler, korrigiert ihn und gut ist es.

Erzählt mir einer, dass das nützlich in der Entwicklung ist, weil man dann eine eigene Fehlermeldung bekommt, dann stimme ich dem zu. Wie gesagt, während der Entwicklung. Dann aber raus.

Denn ich erkenne nicht den Sinn der Zeile im funktionierendem Programm. Entweder ist das Objekt nil, dann erkennt man das vermutlich schon in der Entwicklung, oder nicht, dann stellt sich die Frage wieso die Zeile in einer funktionierenden Prozeduren steht.

Aber vielleicht erkenne ich nur den tieferen Sinn nicht.

[Aphton]

Ich glaube dass es sich hier um eine (unnötige) Optimierung handelt: Asserts werden, wenn ausgeschaltet und soweit ich mich richtig erinnere, gar nicht erst reinkompiliert!

Wenn man also nicht im Debugmodus mit Asserts arbeitet sondern im Release, dann fällt genau die eine Zeile weg.

Kann sein, dass ich falsch liege; aber sonst ergäbe es wirklich keinen SInn!

[jaenicke]

Assertions sind dafür gedacht, dass man bei der Entwicklung bestimmte problematische Werte abfangen kann, ohne dass diese Prüfungen im fertigen Programm anschlagen. Denn für ein Release kompiliert man normalerweise ohne aktivierte Assertions. Das ist in den Projektoptionen auf der Seite Compilieren und somit ohne weitere Anpassungen im Quelltext einstellbar.

Und man erhält bei einem Assert auch die Position im Quelltext, an der das Problem aufgetreten ist, ohne dafür Stacktraces usw. bemühen zu müssen.

[Meflin]

Zitat:

Zitat von Aphton (Beitrag 1241989)

Kann sein, dass ich falsch liege; aber sonst ergäbe es wirklich keinen SInn!

Doch, nennt sich selbstdokumentierender Code - so sehe ich auf den ersten Blick, ob ich als Caller diesen Fall nun selber abfangen muss, oder nicht.

Abgesehen davon kann man mit solchen Asserts nicht erlaubte Zustände nahe an der potentiellen Fehlerquelle abfangen - der auftretende Defekt ist ja in der Praxis sehr oft an einer völlig anderen Stelle zu beobachten, und dann spart man sich durch solche Asserts viel Zeit und Nerven.

[Sir Rufo]

Korrekterweise müsste diese Zeile so im Code stehen

Delphi-Quellcode:

{$IFDEF DEBUG}
Assert( ... );
{$ENDIF}

damit diese korrekterweise nicht in den Produktivcode fließt.

Da man diese Zeilen aber in Code von Anderen für Andere findet, werden diese Zeilen dort mit eingewoben um unbedarften Programmierern so früh wie möglich die Fehler bei der Benutzung des Codes um die Ohren zu hauen.
(gerade falls der Fehler erst später in den Standard-Units zum Tragen kommt, dann heißt es öfter mal "dein Code tut nicht")

Somit ist diese Zeile nur dafür da RTFM-Rückfragen zu minimieren ;)

[Der schöne Günther]

Ohne mich damit richtig auseinandergesetzt zu haben, konnte ich mich damit nie anfreuden. Ich dokumentiere es und werfe eine

Delphi-Quellcode:

EArgumentNilException

wenn jemand doch eine leere Referenz reinsteckt. Läuft doch im Endeffekt aufs Gleiche raus, oder?

[jaenicke]

Zitat:

Zitat von Sir Rufo (Beitrag 1241996)

Korrekterweise müsste diese Zeile so im Code stehen

Delphi-Quellcode:

{$IFDEF DEBUG}
Assert( ... );
{$ENDIF}

damit diese korrekterweise nicht in den Produktivcode fließt.

Nein, gerade nicht...
Wenn du Assertions in den Projektoptionen deaktivierst, wird an der Stelle kein entsprechender Code erzeugt. Das ist daher genau nicht notwendig. Genau deshalb ist es sinnvoll Assertions statt sonstigem Code beim Entwickeln zu nutzen.

[Sir Rufo]

Zitat:

Zitat von Der schöne Günther (Beitrag 1241999)

Ohne mich damit richtig auseinandergesetzt zu haben, konnte ich mich damit nie anfreuden. Ich dokumentiere es und werfe eine

Delphi-Quellcode:

EArgumentNilException

wenn jemand doch eine leere Referenz reinsteckt. Läuft doch im Endeffekt aufs Gleiche raus, oder?

Ja, allerdings ist das auch nur für den Entwickler, denn der hat einen Fehler bei der Programmierung gemacht und dann ist das Assert besser/gleichwertig/einfacher, weil dort auch die Zeilennummer mitkommt ;)

Andere Exceptions (z.B. Socketfehler) können teilweise auch vom Anwender behoben werden (Netzwerkkabel einstecken, Server einschalten, Internetverbindung prüfen, ...) und sind nicht zwangsweise Programmierfehler sondern können auch Kontext-Fehler sein

Zitat:

Zitat von jaenicke (Beitrag 1242000)

Zitat:

Zitat von Sir Rufo (Beitrag 1241996)

Korrekterweise müsste diese Zeile so im Code stehen

Delphi-Quellcode:

{$IFDEF DEBUG}
Assert( ... );
{$ENDIF}

damit diese korrekterweise nicht in den Produktivcode fließt.

Nein, gerade nicht...
Wenn du Assertions in den Projektoptionen deaktivierst, wird an der Stelle kein entsprechender Code erzeugt. Das ist daher genau nicht notwendig. Genau deshalb ist es sinnvoll Assertions statt sonstigem Code beim Entwickeln zu nutzen.

Ok, übergeredet :)

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

Zitat von Popov (Beitrag 1242084)

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:

Zitat von Furtbichler (Beitrag 1242152)

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

Zitat von hoika (Beitrag 1242180)

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