Assertion

[Luckie]

Folgender Code:

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
begin
  Assert(False, 'Foobar');
end;

erzeugt folgende Messagbox:

Zitat:

---------------------------
Project1
---------------------------
Foobar (E:\Delphi\Programme\Unit1.pas, line 28)
---------------------------
OK
---------------------------

Das wird irgendwie mit einkompiliert. Deaktiviere ich die Assertions in den Projektoptionen ist bei D6 Personal die Anwendung 1 KB kleiner, als mit.

[w3seek]

also um es mal klar zu stellen:
Assertions sollte man nur dann benutzen, wenn eine Bedingung im Programmablauf nie falsch sein darf. Zudem sollte man bedenken, dass ein Aufruf auf Assert lediglich eine Ueberpruefung sein sollte und kein Funktionsaufruf, kompiliert man das Projekt naemlich ohne Assertions, wuerde diese funktion niemals ausgefuehrt werden. Also bedingungen in Assertions duerfen niemals den Programmablauf beeinflussen, das Programm muss genauso funktionieren, wenn man den Assert() aufruf einfach weglassen wuerde.

Delphi-Quellcode:

var
  a, b: Integer;
begin
  a := 2 + Random(198);
  b := a div 2; // b ist demnach niemals 0, da a mindestens 2 ist
  Assert(b <> 0, 'Dieser Fehler darf niemals auftreten!');
end;

Das waere zum Beispiel eine Anwendung, wenn auch etwas schwachsinnig in diesem Fall aber normalerweise sollte b in diesem Fall immer ungleich 0 sein (ist es auch), falls nicht stimmt etwas mit dem algo nicht.

Ein anderes Beispiel:
RICHTIG:

Delphi-Quellcode:

var
  hash: String;
begin
  ...
  hash := RegisterAndGenerateFileHash(hFile); // die Funktion sollte immer einen 8-stelligen String zurueckliefern, auch im Falle eines Fehlers
  Assert(hash <> '', 'RegisterAndGenerateFileHash() hat irgendwie einen leeren String zurueckgegeben!');
end;

FALSCH:

Delphi-Quellcode:

var
  hash: String;
begin
  ...
  // die Funktion sollte immer einen 8-stelligen String zurueckliefern, auch im Falle eines Fehlers
  Assert(RegisterAndGenerateFileHash(hFile) <> '', 'RegisterAndGenerateFileHash() hat irgendwie einen leeren String zurueckgegeben!');
end;

Dieses Beispiel zeigt die falsche Anwendung von Assertions, da die Funktion RegisterAndGenerateFileHash niemals aufgerufen wuerde, wenn man das Projekt ohne Assertions kompiliert.

[w3seek]

Zitat von Dax:

Aber wie geht das? Da muss der Compiler doch zur Compilezeit das ganze einfügen (Zeilennummer usw.)...

Richtig, das wird vom Compiler direkt als String fest in die EXE mit einkompiliert.

Zitat von Dax:

Wo ich bei VirtualDub draufgestoßen ist's ähnlich: wenn das Programm crasht, disassembliert es sich und gibt Zeilennummer und Art des Fehlers an. Aber wie geht das mit disassemblen zur Laufzeit und Co?

Das Programm installiert einen Exception handler (mit der Funktion SetUnhandledExceptionFilter()). Falls jetzt eine Exception auftritt, die nicht behandelt wurde, wird eine Callback funktion mit allen noetigen Informationen aufgerufen. Darin kann beispielsweise die Anwendung disassembliert werden und die aktuelle Position errechnet werden. Die Datei und Zeilennummer wird aus den Debug-Informationen ermittelt, die in einer Section hinterlegt sind, dabei wird die naechst kleinere oder gleiche Adresse an der die Exception aufgetreten ist in der Liste gesucht. Dann weiss man in welcher Datei und in welcher Zeile die Exception aufgetreten ist. vielleicht sagt dir das tool addr2line fuer gnu projekte was.

[Ultimator]

Irgendwie wäre doch dein Beitrag GENAU das Richtige für die Code-Lib, oder nicht?

[Dax]

@w3seek: Nee, sagt mir nix. Aber wie geht das denn, mit dem disassembling?