In nonVCL Fehler / Exceptions abfangen ?

[turboPASCAL]

Offtropic

Oh, danke für das Angebot.
Ich nutze da lieber TP 5 oder BP 7 oder Turbo Pascal für Windows.

[sirius]

Seit wann braucht man fürs Exception-Handliung die Sysutils? Die Sysutils organisiert die Exceptions nur auf Ebene der OOP. Baut also eine Klasse um die Exception und Rekonstruiert dieses Objekt im Except-Block (oder erstellt sogar eins, wenn es eine externe Excpetion war).

Try-except sollte immer funktionieren, allerdings nur mit Sysutils kann man die Exception-Klasse nutzen.

[alzaimar]

Zitat von sirius:

Try-except sollte immer funktionieren...

Hmm...

Delphi-Quellcode:

program ExceptionTest;
{$APPTYPE CONSOLE}
Var
  a,b : Integer;

begin
  a := 1;
  b := 0;
  Try
    a := a div b;
  Except
    writeln('Except geht');
  End;
  WriteLn(a); // Damit die Division nicht noch wegoptimiert wird.
end.

Ich müsste also 'Except geht' sehen. Leider hängt sich das Programm auf bzw. terminiert nicht.

[himitsu]

Zitat von sirius:

Seit wann braucht man fürs Exception-Handliung die Sysutils?

Also, das Exception-Object und andere Dinge sind in der SysUtils definiert und initialisiert.

Und ohne eine Behandlung von Exceptions führen dieses zum sofortigen Programmabbruch.


Vielleicht hilft der Anhang etwas.


Der Debugger bekommt von den Exceptions was mit, aber ansonsten hab ich wohl irgendwo 'nen Fehler,
denn die Exceptions werden leider nicht angezeigt.
siehe #21 ... die Exceptions werden doch angezeigt

Außerdem drehen einige Debugger durch.
Das liegt wohl daran, daß dieses Exception-Objekt anders ist, als sie es kennen.
Es wird nach der Exception zwar ordnungsgemäß weitergearbeitet, aber z.B. D2009 hört da mit dem Debuggen auf und das Programm läuft einfach so weiter.
In D7 geht dieses aber.


PS: die Exceptions sind CL ... haben ja direkt nicht mit der VisualCodeLibrary zu tun

[turboPASCAL]

Ohne die Sysutils wird aber das except komplett übersprungen und es ploppt
das "Runtimeerror at 0815xx" auf.

Kannst du ja mit obigen Beispiel ausprobieren.

[turboPASCAL]

Zitat von himitsu:

Außerdem drehen einige Debugger durch.
Das liegt wohl daran, daß dieses Exception-Objekt anders ist, als sie es kennen.

Naja, lieber die Debugger als ich.

Mir wäre halt wichtig das man im except-Block den Fehler loggen kann oder einen validierten Wert zu weisen kann.

Dein Demo kann ich leider noch nicht testen, SAccessViolationNoArg und einige Andere sind D6 wohl unbekannt.
Mal sehen...

[himitsu]

bei dieser Konstannte kannst'e im Notfall erstmal einfach die ' drumrummachen

'SAccessViolationNoArg' Nja, es ist halt so einiges mit der Zeit dazugekommen, umbenannt wurden oder es wurde umgelagert.

[turboPASCAL]

Jo, passt schon.

[sirius]

Zitat von himitsu:

Also, das Exception-Object und andere Dinge sind in der SysUtils definiert und initialisiert.

Habe ich ja geschrieben.

Zitat von himitsu:

Und ohne eine Behandlung von Exceptions führen dieses zum sofortigen Programmabbruch.

"Ohne Behandlung" ist die falsche Wortwahl, denn einen Except-Block hat TP ja angegeben. Das Problem ist nur (was ich vorhin noch nicht wusste), das Delphi auf Teufel komm raus aus jeder Exception ein Exceptionobjekt bauen will, was man dann im Except-Block abfragen und auswerten kann. Und wenn Delphi kein Objekt zustande bekommt, dann beendet Delphi einfach das ganze Programm, was recht radikal ist (denn hier wertet TP bspw. gar kein Exceptionobjekt aus und bräuchte es nicht einmal).

[himitsu]

Nja ... Try-Except hat er vielleicht, aber deswegen werden die Exceptions nicht "behandelt",

bzw. wenn nichts Anderes in der Unit System angegeben ist, dann leitet diese die Exceptions direkt an Windows weiter RaiseException und dieses reagiert dann so

Zitat:

the default action is to call the ExitProcess function.

Obwohl ... müßte man Hagen oder Olly mal fragen ... ich glaub Try-Except war 'nen "frame-based handler"?