Re: Try Finally...

From: Martin Harvey (Demon account) (martin_at_nospam_pergolesi.demon.co.uk)
Date: 10/25/04 

Date: Mon, 25 Oct 2004 18:20:32 GMT

On Mon, 25 Oct 2004 13:41:12 +0200, "Maarten Wiltink"
<maarten@kittensandcats.net> wrote:

>How is this non-continuable? The CD can be put back and the read operation
>restarted.

Apart from a bug in some older versions of windows to do with demand
paging of code from removable media....

>
>[...]
>
>> Try/Except/Finally is not Structured Exception Handling. It is a
>> language specific (c++) *interface* to windows standard SEH. It wasn't
>> all that long ago David and I spent a couple of weeks getting this all
>> sorted out.
>
>C++? Where did that come from?

That's erroneous, but the sentiment is correct. the Delphi exception
handling constructs are a wrapper around the win32 structured
exception handling mechanism which allows you to daisychain handlers,
and involves some interesting algorithms.

>> Now WINDOWS takes over and begins unwinding the exception list.
>
>This is an implementation detail. I couldn't care less _who_ unwinds
>the stack, as long as the exception gets handled by the book.
>A programming language is a virtual machine.

Windows unwinds the exception list, but ISTR that on the second
traversal, some app specific code has to help unwind the stack.

>>> That's the whole idea of a finally block. It's not supposed to handle
>>> exceptions.
>>
>> Yet, oddly enough it's invoked by them all the time.

Poor terminology ... we should distinguish between execution on
exception, and exception "handing" in the sense of "removal".

>> The problem is that **when invoked by an exception** the current Delphi
>> implementation of "Finally" *always* terminates the program... there is
>> no carrying on.

No it doesn't terminate the program ... it simply doesn't handle (i.e.
remove) the exception. However, other handlers further down the chain
can catch the exception, and execution of the program then can
continue from within the context of those handlers. You seem to be
forgetting the chained / nested properties of these handlers.

MH.

Relevant Pages

  • Re: Windows Form Level Exception
    ... No, there's nothing like that in Windows Forms, as far as I know. ... you should think of such global handlers only as of a "safety ... My recommendation is to have exception handlers everywhere an exception ... displaying error messages, but catch errors as close to the place they ...
    (microsoft.public.dotnet.framework)
  • Re: How to determine if calling app is window or console
    ... different global exception handlers. ... It can be beneficial to combine the above global handlers in your app, ... In my Windows Forms apps I would have a handler attached to the ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Try Finally...
    ... finally continues at the point where the exception is handled. ... the Windows mechanism takes a two-stage ... with the first stage only following the stack and the second ... execution finally continues after the handler that handles the exception. ...
    (comp.lang.pascal.delphi.misc)
  • Re: initial lang spec: SXIL...
    ... Shouldn't some of that functionality be moved into the exception ... but, of course, natively using SEH requires compiler support. ... throws a fixed exception code in my case, and generic handlers are used. ... It took many years, and a language review, before I realized that my fond ...
    (comp.lang.misc)
  • Re: Runtime Syntax Checker
    ... Have a similar to the (good times gone by 68k exception] ... global handlers ... interp alias warning handle warning ... handler warning msg ...
    (comp.lang.tcl)