Re: CLI Exception Handling

From: Mike (anonymous_at_discussions.microsoft.com)
Date: 04/14/04 

Date: Wed, 14 Apr 2004 06:46:11 -0700

Thank you guys for your helpful responses. So it is indeed (currently) not possible to resume execution from where the exception was thrown.

I have been playing a little since my post, and, from what I have found, the ability to transfer execution to an IL instruction in a "try" block from its corresponding handler (with the IL "leave" instruction) has two drawbacks that prevent true resuming of execution after a thrown exception:

1. The leave must return to a point where the evaluation stack is empty. This is often not the situation at instructions where exceptions are thrown.

2. It is practically quite difficult to determine (in the handler block) from which IL instruction the exception was thrown.

Thanks again

Mike

----- Dave wrote: -----
     
> 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.
     
> 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.
     
     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.
     
     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.
     
>> The only way that section of the spec makes sense is that a user filter
>> could make the decision whether to resume, continue searching, or
     execute
>> the catch handler (similar in concept to win32 seh) but currently all it
>> really can do is make a decision to continue searching or execute the
>> handler. All a type filter can do is execute the handler or keep
>> searching -
>> more complex decision making would be hard to achieve.
>> It doesn't actually need to decide to resume. If you write a given filter
> with a handler that will do the resume, by deciding to execute the handler
> it is choosing to resume. You in effect create one handler that chooses
> resume or continue searching, while others chose execute handling code or
> continue searching.
     
     We are talking apples and something else.
     
>>> At the IL level, there is no apparent restrictions on what you can do in a
> user filter. VB has a fair amount of restriction on a language level
> however, as I think it only allows a single statement(which can be a
     method
> call).
>
     
     Agreed. That's what I said. VB only allows simple expressions within the
     When clause; the IL does not impose this restriction.

Relevant Pages

  • Re: How to troubleshoot bugchecks on my own?
    ... not a memory problem. ... From that exception record and context, ... execute the instruction - without a problem. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: System.Security.SecurityException was unhandled
    ... The exception gave you the CLSID. ... the first thing to check might be whether the COM server ... assembly actually has the permission in question. ... When I execute the application I received and error message. ...
    (microsoft.public.dotnet.security)
  • Re: PROBLEM: Caught SIGFPE exceptions arent reset
    ... On an i386, you can set a handler for a SIGFPE signal, and after enabling FP ... exceptions with feenableexceptions, ... underlying FP instruction set and its exception model, ... or by changing the PC so that the failed instruction is skipped ...
    (Linux-Kernel)
  • Re: PROBLEM: Caught SIGFPE exceptions arent reset
    ... exceptions, changing the operands of the failed FP instruction, ... or by changing the PC so that the failed instruction is skipped ... Given the current SIGFPE handling in the kernel, a userland handler ... CAN'T mask the exceptions or clear the exception flags. ...
    (Linux-Kernel)
  • Re: collecting results in threading app
    ... but execute one at the time'. ... Could a Queue help me there? ... You can take a look at papyros, a small package I wrote for hiding ... # some exception was raised when executing this job ...
    (comp.lang.python)