Re: Exception Handling...
nobody_at_noplace.not
Date: 06/25/04
- Previous message: Rob Kennedy: "Re: Simple threading question"
- In reply to: David Reeve: "Re: Exception Handling..."
- Next in thread: nobody_at_noplace.not: "Re: Exception Handling..."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 25 Jun 2004 00:28:23 -0400
On Fri, 25 Jun 2004 02:32:34 GMT, "David Reeve" <dree4456@big-pond.net.au>
wrote:
>A couple of points that you might or might not know, which also might or
>might not be correct, but is based on what I have gleaned to date. I'll do
>some more digging around on the weekend.
Hey... right now I'm not so sure I know anything about this... [grin]
FWIW... I'm not worried about Linux, just windows.
>a) since D2, Delphi uses the SEH system of the W32 OS
>b) most of the exception behaviour is occuring in the OS and you won't find
>the code in Delphi
Yes, correct... except for things like range checking, etc. it's all done in
the OS... I/O errors, Memory errors etc all have to be specifically
remapped from windows codes to delphi codes (in the sysutils unit) to get
them to act like delphi exceptions.
I do know from digging around that it is possible for an application to
define a list of private exceptions, so long as their "magic numbers" don't
overlap those embedded in the OS. The defaults are detailed in windows.pas
lines 330 -- 366 as "Status" signals and remapped in SysUtils lines
13585-13616. Delphi is apparently doing some of this so that the OS passes
them on to the "unhandled exceptions" handler.
Note: line numbers are approximate.
>Forget, for the moment, exceptions raised in delphi code using the raise key
>word.
Yes, Delphi's internal errors (range, ioerror, etc.) are reported through
"unhandled" exceptions by the os using the RaiseException windows import.
But Delphi also has it's own dialog for that in sysutils.pas at line 13200
as ShowException. This at least explains the annoying tendency to produce
two dialogs for the same error. One is from windows the other from Delphi.
>Exceptions will be generated at the machine level by code running in
>user mode, and these will be handled firstly by the OS. The machine state is
>grabbed into the context record so that recovery is possible should an
>exception handler be located. The OS then unwinds the stack frame of the
>thread which executed the errant code, procedure call by procedure call as
>it looks for what??........
According to the SDK it's looking for the address of the exception handler.
>Some sort of datastructure embedded in the stack
>frame I guess, which indicates the preceding procedure in the call sequence
>was bracketed by a try...except block, and that it should handled by the
>code at such and such an address. Note that no Delphi code need be run until
>the exception code is entered.
I don't understand the exact mechanism of it just yet but the "stack frames"
you speak of can be found in SysInit.pas where Delphi is making TLS (thread
local storage) areas for each thread it launches. I have been able to
figure out (if I'm correct) that the first dword in the TLS is an
except-code and the second seems to be a jump address. But I still haven't
figured out how these get updated or executed... i.e. how does Delphi get
the signal to go there?
>What you have to work out is what Delphi does when it compiles a
>try...except block, and the best way to do this is to compile a simple
>example with and without the block and step the code at the assembler level.
I haven't gotten quite that far into it yet. I'm not the most proficient
asm person so that's hard work for me... But, I'm not about to give up
either...
This has been quite helpful... I knew some of it already but this is an
excellent confirmation. Thanks!
-----
Laura
- Previous message: Rob Kennedy: "Re: Simple threading question"
- In reply to: David Reeve: "Re: Exception Handling..."
- Next in thread: nobody_at_noplace.not: "Re: Exception Handling..."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
