Re: Try Finally...
From: L D Blake (not_at_any.adr)
Date: 10/28/04
- Next message: Maarten Wiltink: "Re: Try Finally..."
- Previous message: Maarten Wiltink: "Re: Try Finally..."
- In reply to: VBDis: "Re: Try Finally..."
- Next in thread: Maarten Wiltink: "Re: Try Finally..."
- Reply: Maarten Wiltink: "Re: Try Finally..."
- Reply:(deleted message) VBDis: "Re: Try Finally..."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 28 Oct 2004 04:47:13 -0400
On 28 Oct 2004 07:59:05 GMT, vbdis@aol.com (VBDis) wrote:
>Im Artikel <2u8158F2706ubU1@uni-berlin.de>, Rob Kennedy <me3@privacy.net>
>schreibt:
>
>>If SysUtils is not used, then system exceptions are not transformed into
>>Delphi exceptions, and so Delphi's try-except blocks don't handle them.
>
>Okay, so one big part of Delphi SEH requires conversions for system exceptions,
>interrupts, assertions and other Delphi exceptions into Delphi SEH structures.
OK lets try and clear some of this up. Structured Exception Handling is a
Windows thing. It is governed by guard frames placed in the program's stack.
These frames are put in place by Delphi's TRY keyword. Each frame contains
(at minimum) the address of an exception handler and a pointer on the stack to
the previous frame.
The exceptions themselves originate from Windows, not Delphi. Delphi cannot
raise an exception... it has to ask windows to do that.
When an exception occurs Windows, not Delphi, walks the stack looking at the
guard frames and, in turn, asking each exception handler if it's interested in
taking care of the problem. This process can be very simple, as in the case
of an Except keyword which basically takes any exception that comes along and
calls it fixed. Or it can become horrificly complicated with handlers
registered only for specific types of exceptions (eg. One that only handles
memory errors).
At the top of the list (because the stack grows downward in memory) is a guard
frame for "unhandled exceptions". If nothing else catches an exception, this
does... and Windows "unhandled exception handler" then closes down the
application. Applications can put in their own unhandled exception handlers
and produce their own shutdowns and error messages... which Delphi does.
In Delphi these guard frames are created at the beginning of a TRY block and
removed at the beginning of the Finally or Except block. Any exception that
does not occur within the Try block is going to end up in the Unhandled
Exception Handler. And, since each program has it's own stack space,
exceptions from other applications never get into places they're not supposed
to.
It's rather simple... but horridly complex at the same time.
When an exception comes along, Windows walks the stack looking for a handler.
Delphi catches it and does it's thing making that exception into the objects
that you all like to play with.
The hard part for us to understand is that when we do something that causes an
exception, the exception is not created in Delphi (or whatever language we are
using), it originates in the operating system. What the language does with an
active exception is entirely up to the language (and by extension, us).
>Consequently a replacement SEH should specify what it supports, at least:
>- Delphi version
>- which kinds of error conditions (by triggering Delphi exception handling)
>- exceptions during exception handling (in exception handling code)
>- debugging
>- possibly non-standard behaviour of Except and Finally
Yeah well... that's rather a dead horse now, isn't it?
-----
Laura
http://www.start.ca/users/ldblake
- Next message: Maarten Wiltink: "Re: Try Finally..."
- Previous message: Maarten Wiltink: "Re: Try Finally..."
- In reply to: VBDis: "Re: Try Finally..."
- Next in thread: Maarten Wiltink: "Re: Try Finally..."
- Reply: Maarten Wiltink: "Re: Try Finally..."
- Reply:(deleted message) VBDis: "Re: Try Finally..."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
