In nonVCL Fehler / Exceptions abfangen ?

[turboPASCAL]

Hi,

ich schon wieder. :stupid:

da ich einem undefinierbarem Fehler auf der Spur bin, habe ich mir gedacht
man könne ja Quelltextteile mit try & except erst ein mal eingrenzen.
Leider ist dem anscheint nicht so, except wird ignoriert.

Testapp:

Delphi-Quellcode:

program Blah;

type
  DWORD = Cardinal;

function msgb(hWnd: DWORD; lpText, lpCaption: PChar; uType: DWORD): Integer;
  stdcall; external 'user32.dll' name 'MessageBoxA';

var
  n, i: integer;

BEGIN
  SetLastError(0);

  i := 1;
  dec(i);

  try
    n := 50 div i;
  except
    n := -1;
  end;


  if n <> 0 then msgb(0, 'Huch.', '!', 0);
END.

[Sir Rufo]

Ja und was soll da deiner Meinung nach passieren?

Soll da etwa eine MessageBox aufpoppen?

Die poppt auf, wenn n größer als 0
Im Exception-Fall ist n aber kleiner gleich 0 -> -1

cu

Oliver

[turboPASCAL]

Ja, Tippfehler n<>0.
Das ist eigentlich dazu da, damit die Compilermagic nix weg optimiert.

[Sir Rufo]

Zitat:

Zitat von turboPASCAL

Ja, Tippfehler n<>0.
Das ist eigentlich dazu da, damit die Compilermagic nix weg optimiert.

Der Tippfehler hilft gegen die Compilermagic :gruebel: sehr interessant :mrgreen:

Besteht der Fehler immer noch, oder ist das durch die Korrektur des Tippfehlers behoben?

cu

Oliver

[turboPASCAL]

Es geht darum das der Except-Block ignoriert wird.
Nehmen wir die SysUtils auf funktioniert der Except-Block wie erwartet.

Also kann man bei nonVCL try & except in die Tonne verschieben ?

[thkerkmann]

Ja, kann man.
Sysutils installiert das Exception Handling.

[Wolfgang Mix]

Dank für die Erkenntnis.
Fummele schon 'ne ganze Zeit mit dem Fehler herum,
konnte ihn aber bei automatisch eingebundenen SysUtils nicht reproduzieren.

Gruß

Wolfgang

[DeddyH]

Das kommt ja darauf an, wie man nonVCL definiert. Für mich ist das einfach der Verzicht auf TForm etc., das schließt SysUtils ja nicht aus.

[turboPASCAL]

Zitat:

Zitat von DeddyH

Das kommt ja darauf an, wie man nonVCL definiert. Für mich ist das einfach der Verzicht auf TForm etc., das schließt SysUtils ja nicht aus.

Ja, das mag stimmen.

Ich habe es halt gern pure API. :mrgreen:

[DeddyH]

[OT] Ich hab hier noch irgendwo die CD "TP 1.5 for Windows", wär das nix? :mrgreen: [/OT]

[turboPASCAL]

Offtropic

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

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

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:

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

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

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

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

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

Delphi-Quellcode:

'SAccessViolationNoArg'

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

[turboPASCAL]

Jo, passt schon. :thumb:

[sirius]

Zitat:

Zitat von himitsu

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

Habe ich ja geschrieben.

Zitat:

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"? :gruebel:

[himitsu]

[INFO]
ich bin blöd :wall:
die Exception wird doch im Programm angezeigt ... also wenn man sie nicht mit Try-Except abfangen würde :oops: