Assertion

[day]

Hallo

gibt es eingentlich die möglichkeit in Delphi Assertions zu verwenden?

[Muetze1]

Moin!

Klar, Assert() macht dieses. Benutze ich selber recht gerne...

MfG
Muetze1

[day]

und wie kann man sie deaktivieren?

[Muetze1]

Moin!

Projekt->Optionen->Compiler->Assertions (C) abwählen und Programm neu erstellen...

MfG
Muetze1

[Dax]

Für was ist Assert() eigentlich gut?

[Muetze1]

Moin!

Damit kannst du Bedingungen in deinem Programm testen. Dies ist sinnvoll während der Entwicklung, um möglichen Fehlern auf die Schliche zu kommen.

z.B. in diesem Code sollte der Sender lieber ein TEdit sein:

Delphi-Quellcode:

Procedure TForm1.Edit1Change(Sender : Tobject);
Begin
  TEdit(Sender).Enabled := True;
End;

Grundsätzlich sollte es keine Probleme machen, aber angenommen du hast dich einmal verklickt im OI und ein Button hat nun auch die Methode zugewiesen bekommen. Durch den harten TypeCast TEdit() wird keine Überprüfung vorher durchgeführt ob es wirklich ein TEdit ist (im Gegensatz zu As TEdit). Daher kann der Code leicht ins Nirvana gehen bzw. am Button Einstellungen überschreiben.

Bsp: Assertions:

Delphi-Quellcode:

Procedure TForm1.Edit1Change(Sender : Tobject);
Begin
  Assert( Sender Is TEdit, 'Argh: Edit1Change(): Sender ist kein TEdit - wahrscheinlich falsch zugewiesen!');

  TEdit(Sender).Enabled := True;
End;

Wenn du nun dein Programm startest und den Button mit der falschen Methode aufrufst, dann kommt eine Assert mit dem selbst definierten Text hoch - schlimmeres verhindert, du weisst wo du ansetzen musst und hast es ohne grossen Endtest und debugging schnell gefunden...

MfG
Muetze1

[Dax]

Merk' ich mir - könnte nützlich sein. ;)

[sakura]

Luckie hatte mal einen Thread zu diesem Thema gestartet.

...:cat:...

[Luckie]

Und der Gag an der ganzen Sache ist: Die Zeilennummer steht mit in der Messagebox von Assert. ;)

[Dax]

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

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?

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

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:

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?