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!

[Meflin]

Zitat von Aphton:

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 EArgumentNilException wenn jemand doch eine leere Referenz reinsteckt. Läuft doch im Endeffekt aufs Gleiche raus, oder?

[Sir Rufo]

Zitat von Der schöne Günther:

Ohne mich damit richtig auseinandergesetzt zu haben, konnte ich mich damit nie anfreuden. Ich dokumentiere es und werfe eine 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 von jaenicke:

Zitat von 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.

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

[jaenicke]

Zitat von 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.

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.

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