Re: Try Finally...

From: Maarten Wiltink (maarten_at_kittensandcats.net)
Date: 10/25/04

  • Next message: Marco van de Voort: "Re: Try Finally..." 
    Date: Mon, 25 Oct 2004 15:11:06 +0200

    "L D Blake" <not@any.adr> wrote in message
    news:kbspn05tc0pm6ginhdm592fr8jt2f6ggso@4ax.com...
    > On Mon, 25 Oct 2004 13:41:12 +0200, "Maarten Wiltink"
    > <maarten@kittensandcats.net> wrote:
    [...]
    >> 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.
    >
    > Okey dokey... so what's your stake in the way SEH works then... just
    > take what they give you and don't question it.

    My stake is in how you are claiming to make Object Pascal work in
    fewer bytes. What I see is that your language uses the same syntax
    as Object Pascal, but has different semantics. Specifically the
    try-finally statement _means_ something decidedly different.

    I don't have a problem with that. It's interesting. But don't call it
    Object Pascal. And start by defining rigorously what your language does,
    even if it's only by contrast to Object Pascal behaviour. Defining a
    language by the behaviour of whatever this week's patch does, is a
    poor offering.

    >> Besides, how would the outermost finally handler carry on? By then,
    >> the stack is completely unrolled.
    >
    > No it isn't...

    It's not? Okay, I can see how that's possible. The stack is unwound
    (stack frames followed back, SP updated), but left in place, and the
    program state at the moment the exception is raised is kept around,
    or perhaps one handler level out, or whatever.

    What happens if a hardware interrupt arrives during exception processing?
    That overwrites the stack. Disabling interrupts seems a bad solution,
    since the exception handlers are user-level code. There might be a
    ShowMessage in there for all you know. Switching stacks is another
    option, but it seems a bit heavy-handed.

    > You really should get just a little below that high level haze
    > you keep expounding and learn some about how this stuff works...
    > it really is quite fascinating.

    Oh yes, no argument. I'm delighted that these things are still done.
    It's just not my hobby, so I'm _quite_ happy to let you do the hard
    work. Trying to shoot holes in it is definitely the easy part. And I'm
    not doing that to spite you; I just think that if it's worth doing,
    it's worth doing well.

    Your try-except handling replacement, for example, may be a godsend
    for somebody who doesn't need the features it doesn't offer and _does_
    need the few kilobytes it doesn't require. But I think you should not
    make light of those missing features, and that anybody who doesn't
    need a lightweight RTL doesn't stand to gain anything by it.

    Groetjes,
    Maarten Wiltink

  • Next message: Marco van de Voort: "Re: Try Finally..."

    Relevant Pages

    • Re: Exception Handling...
      ... >>The try key word results in the current stack frame base, ... > private data on top of the Exception Registration... ... is the address of the exception handler. ... >>Immediately following this jump, there is inserted a jump to ...
      (comp.lang.pascal.delphi.misc)
    • 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: ada compiler?
      ... high that the exception handler itself will overflow the stack (e.g. ... Storage_Error (without any further operations in the handler) would fail the ...
      (comp.lang.ada)
    • Re: VB6 How to find calling routine
      ... it means once a handler has captured ... an exception, most of the original stack context has gone because the stack ... to track all the calling routines is just too much work for too little ...
      (comp.lang.basic.visual.misc)
    • Re: crash in release build
      ... If you don't have any idea where it's crashing (like the call stack), ... // Add the event handler for handling UI thread exceptions to the ... // Set the unhandled exception mode to force all Windows Forms errors ... // Add the event handler for handling non-UI thread exceptions to the ...
      (microsoft.public.dotnet.languages.csharp)