Re: CLI Exception Handling
From: Daniel O'Connell [C# MVP] (onyxkirx_at_--NOSPAM--comcast.net)
Date: 04/14/04
- Next message: Gang Peng[MSFT]: "RE: GC: Performance impact of large static structure in memory"
- Previous message: Mike: "Re: CLI Exception Handling"
- In reply to: Dave: "Re: CLI Exception Handling"
- Next in thread: Dave: "Re: CLI Exception Handling"
- Reply: Dave: "Re: CLI Exception Handling"
- Reply: Dave: "Re: CLI Exception Handling"
- Messages sorted by: [ date ] [ thread ]
Date: Wed, 14 Apr 2004 11:49:23 -0500
"Dave" <noSpamdlevineNNTP2@wi.rr.com> wrote in message
news:ujR$$egIEHA.2656@TK2MSFTNGP11.phx.gbl...
>> Actually, within a catch you are quite capable of returning to any point
>> within the associated try block using leave.
>
> "leave" is not a keyword defined in VB .NET. "__leave" is a C keyword used
> in win32 SEH. It allows you to leave a try block without causing abnormal
> termination and incurring a performance penalty; it does not allow you to
> leave a catch block. Unless you are talking about some other leave
> instruction. Or something else.
It is also an IL instruction. It is required to leave a finally or catch.
>
>> VB actually uses this to
>> implement its On Error Resume functionality. In my trivial experiments it
>> appears that the VB compiler tracks statement points and always considers
>> the next line to be a point where the evaluation stack is expected to be
>> empty, so it resumes execution at the start of the load instructions used
> to
>> fill the stack. You would have to use a filter to ensure that the
> exceptoin
>> is actually processed by the code interested in generating a resume.
>> >
>
> That's not the same thing that I was referring to. VB allows you to resume
> execution on the line of code that follows the instruction that generated
> the exception, but not on the same instruction that actually generated the
> exception. A true restartable exception will resume execution on the
> instruction that generated the exception. This functionality is not built
> into the runtime even though the spec says it does. None of the languages
> I
> know of support it, probably because the runtime doesn't either. This
> functionality does exist in win32 SEH.
No, its not. I initally misread your post. However I don't think the per
instruction resume is something that *should* exist. When you are working
with multiple apparent instruction sets and multiple possible
arcitectures\OS's, I'm not convinced that trying to get an implementation
that will always work properly is a good idea.Too many rules, too many
possiblities. I wonder if such semantics would resume the IL instruction
that failed or the machine instruction.
> The differences are deeper then that, because a user-filter executes while
> running on top of the stack that generated the exception. When the catch
> handler executes all finally blocks that were lower on the stack have
> already run and the stack has been cleaned up. In a true resumable
> exception
> the stack will not have been cleaned up and the finally blocks will not
> have
> run. The resume semantics are implemented in the first pass of the two
> phase SEH.
>
I personally think this design is better. In a system with a evaluation
stack, true resumable instructions is a very bad design, IMHO. Statement
resume is much more valueable considering most of us arne't writing in IL.
It does reqiure however that the compiler store values in the evaluation
stack into locals so that the stack can be rebuilt.
> VB uses what amounts to using a goto within a method body to transfer
> control to implement its resume semantics. This may look like a SEH resume
> but under the hood it's not. It's unstructured exception handling, which
> is
> completely different then the structured exception handling defined in the
> spec. It appears that you cannot combine the two forms of error handling
> within the same method body - vb will refuse to compile it.
>
No, it *is* structured exception handling that looks like unstructured
exception handling. The compiler uses a filtered catch and issues a leave
instruction to the initalization point for the associated statement.
Not mixing the two is a VB restriction, its quite possible to mix them if
you can create workable syntax. If VB hadn't been limited to the god awful
On Error Resume syntax, it would have been possible to mix the two.
- Next message: Gang Peng[MSFT]: "RE: GC: Performance impact of large static structure in memory"
- Previous message: Mike: "Re: CLI Exception Handling"
- In reply to: Dave: "Re: CLI Exception Handling"
- Next in thread: Dave: "Re: CLI Exception Handling"
- Reply: Dave: "Re: CLI Exception Handling"
- Reply: Dave: "Re: CLI Exception Handling"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|