Re: Try Finally...

From: L D Blake (not_at_any.adr)
Date: 10/29/04 

Date: Fri, 29 Oct 2004 01:14:17 -0400

On 29 Oct 2004 03:12:36 GMT, vbdis@aol.com (VBDis) wrote:

>In so far I don't like to speak of "the stack", the guard frames form their own
>stack (linked list), and walking the call stack (frames) is different from
>walking the guard list.

Correct.

>>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).
>
>This applies to "external" exceptions only. There exists no real need to signal
>internal exceptions (range checks...) to the OS, it's sufficient when both
>internal and external exceptions trigger the same exception /handling/.

Correct.

Think of it as "cooperation" not "unification".

>Walking the guard list also is not problematic, regardless of whether it's
>performed in 1 or 2 passes. In a 2-pass traversal an applicable exception
>handler is determined first, and in the second pass the termination handlers
>are invoked, followed by the exception handler determined in the first pass.

Not actually. The reason for two passes is Debugging. On the first pass the
debugger is asked if it wants the exception... then the stack frame is walked
looking for a handler. On the second pass the debugger is asked again and if
not the unwinding process begins looking for the unhandled exception handler.

First pass ... "Wanna fix this"
Second pass ... "We're outa here"

>The second pass is not initiated when the filter expression decided to resume
>at the instruction that caused the exception(?). It should be noted that the
>exception handler executes only after all termination handlers have executed.

Other way around... the termination handler executes only when all other
handlers have declined to handle the exception.

>This can be done in a single pass as well, but then the guard list must be
>truncated at the same time, because the handlers become no more elective for
>another execution, and the stack must be unwound at the same time, so that the
>handlers execute in their proper stack frame.

Delphi does this in a single pass. The "unwind" pass is ignored. This seems
pretty common in most languages using Try/Except.

BTW, I just spend the evening looking at how FPC handles exceptions... Objects
again... [sigh]

-----
Laura

Relevant Pages

  • Re: Try Finally...
    ... >different viewpoint between language constructs and S.E.H. constructs. ... SEH (Structured Exception Handling) is a stack based mechanism **administered ... Try/Except and Try/Finally are the car around the SEH engine. ... the exception handler registered in the stack. ...
    (comp.lang.pascal.delphi.misc)
  • Re: Try Finally...
    ... Now we can protect every more or less specialized action ... an error indication (exception or error code) has to be ... an according exception handler can be inserted into the code. ... resources, as they are related to specific actions. ...
    (comp.lang.pascal.delphi.misc)
  • Re: WinForms bug? ThreadException not invoked on Exceptions in system code pre-processing the me
    ... Message Queue and invoking the appropriate handler. ... if an Exception is raised during the PRE-PROCESSING of a Windows ... And because any handling will probably fail if there is no memory, the CLR will terminate the application without attempting to call the ApplicationException or UnhandledException events. ...
    (microsoft.public.dotnet.framework.windowsforms)
  • Re: BackgroungWork taske ended for no appearent reason
    ... To do the same thing with Try/Catch blocks requires wrapping every file access with a Do While ... ... If there was any exception thrown in your DoWork event handler, ... If the operation raises an exception that your code does not handle, ... Microsoft Online Community Support ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Frame-based exception handling problem on Server 2008
    ... In this case, the exception ends fatal, usually Cygwin creates a stack ... The Cygwin DLL is a POSIX ... handler is supposed to be *the* exception handler for Cygwin ... It also does not know if the signal handler returns or not. ...
    (microsoft.public.win32.programmer.kernel)