Re: Exception Handling - help!

From: Jonathan Keljo [MS] (jkeljo_at_online.microsoft.com)
Date: 11/06/04 

Date: Sat, 06 Nov 2004 00:43:29 GMT

Hi Dave, George--
     Great investigative work on this thread. George's experiments have
indeed arrived at the intended behavior.

     If an exception is thrown while executing a filter, and it escapes the
filter, the filter is indeed considered to have returned
exception_continue_search. (I had thought this was well documented, but the
only place I could find it is in Partition III.3.34 in the ECMA spec, which
describes the endfilter instruction.)

    Nesting of exceptions in general is cute. As far as I can tell this
isn't documented anywhere, and it's not clear to me whether this should be
specified in the ECMA spec, or chalked up to the vagaries of Windows SEH.
The rule(s) of thumb for exceptions thrown from finally/fault blocks (or
from functions called by finally/fault blocks) are:

1. If the nested exception does not escape the finally/fault block, the
finally/fault will continue executing after the nested exception is caught.
Naturally the second pass of the outer exception will continue normally.
2. If the nested exception DOES escape the finally/fault block, the second
pass of the outer exception is aborted and the nested exception becomes the
outer exception.

This can be generalized to any level of nesting, though why in the world
you'd want to escapes me. These rules are also true for catch blocks,
though conceptually you can think of a catch block as being run _after_ the
end of the second pass.

One interesting behavior that can result from this is that you can have an
exception go "unhandled" without taking down the process. If the outermost
exception goes unhandled, but the nested exception is handled after
escaping from the finally in which it was thrown, the second pass of the
outermost exception will be aborted and the process will keep going.

Jonathan
CLR Exception System Program Manager

This posting is provided "AS IS" with no warranties, and confers no rights.

--------------------
| Thread-Topic: Exception Handling - help!
| thread-index: AcTCYpnvYALC1JuhQluefyvFGqqP4w==
| X-WBNR-Posting-Host: 129.132.1.4
| From: =?Utf-8?B?R2Vvcmdl?= <George@discussions.microsoft.com>
| References: <DBE66BDF-B746-4077-89EE-8996635E8B78@microsoft.com>
<Oi8ipzTwEHA.4048@TK2MSFTNGP15.phx.gbl>
<8E53C9F9-54C8-4FF9-925A-5FEF78A07018@microsoft.com>
<eYlM7eZwEHA.1408@TK2MSFTNGP10.phx.gbl>
<B81BC8C3-90E4-47BB-BAD1-14AB098DEE44@microsoft.com>
<uqztQ$lwEHA.3624@TK2MSFTNGP09.phx.gbl>
| Subject: Re: Exception Handling - help!
| Date: Thu, 4 Nov 2004 03:37:01 -0800
| Lines: 33
| Message-ID: <1BB07850-5E71-4DD2-8469-061E8FA0B2B7@microsoft.com>
| MIME-Version: 1.0
| Content-Type: text/plain;
| charset="Utf-8"
| Content-Transfer-Encoding: 7bit
| X-Newsreader: Microsoft CDO for Windows 2000
| Content-Class: urn:content-classes:message
| Importance: normal
| Priority: normal
| X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0
| Newsgroups: microsoft.public.dotnet.framework.clr
| NNTP-Posting-Host: TK2MSFTNGXA03.phx.gbl 10.40.1.29
| Path: cpmsftngxa10.phx.gbl!TK2MSFTNGXA03.phx.gbl
| Xref: cpmsftngxa10.phx.gbl microsoft.public.dotnet.framework.clr:12199
| X-Tomcat-NG: microsoft.public.dotnet.framework.clr
|
| > > not "execute handler" but "continue search" = look for the next
filter or
| > > catch that might want to handle the initial exception.
| > >
| >
| > That doesn't sound quite right. It doesn't make sense that a nested
| > exception's search for a handler would be terminated just because it
reaches
| > the site of the the original thrown exception.
|
| when the 2nd exception reaches in the filter of the original exception,
the
| first pass (stackwalk) is complete - for the 2nd exception. And then the
| original exception continues its stackwalk (exactly as if the filter
would
| have returned 0 = false).
|
| > If anything I would expect
| > the following - the 2nd exception starts a new exception sequence
(stackwalk
| > looking for a catch handler, executing filter expresssions), and when a
| > catch handler for the 2nd is found the original exception is thrown
away.
|
| No. You are still in the filter of the original exception - you cannot
| propagate further the 2nd exception. You go ahead evaluating the filter
of
| the original exception.
|
| I will post an example.
|
| > Also, per your other reply, I'm do not believe that there's a linked
list of
| > exception events
|
| I'm thinking so because I see the exception are not lost. You start the
| mechanism for one exception, you encounter another exception but the
first is
| still saved somewhere - related to what I state in the first part of this
| message.
|
| Regards, George
|

Relevant Pages

  • Re: Exception Handling - help!
    ... >> invoked during the user filter would have to be on top of the stack, ... > are you sure these routines have access to the faulting frame? ... >> to treat this as a nested exception. ...
    (microsoft.public.dotnet.framework.clr)
  • Re: Exception Handling - help!
    ... | to also be in Partition I.12.4.2.5, the overview of Exception Handling. ... | filter block - is this true only for inline code, ... | (which it was not when the exception was thrown). ... | nested exception the new exception would have to walk the stack anyway ...
    (microsoft.public.dotnet.framework.clr)
  • Re: DirectShow Transcoding Woes
    ... to assume that the addition of a particular filter ... results in the exception being thrown by RenderFile. ... faults are not supposed to happen and the code ...
    (microsoft.public.win32.programmer.directx.video)
  • ISA2004 Firewall fails to start & event id 14057
    ... a 3rd party filter installed and occasionally I am ... When attempting to start the firewall in the ISA server manager I sometimes ... again saw exception 6D9 messages during module loading as follows: ...
    (microsoft.public.isa.configuration)
  • Re: Exception Handling - help!
    ... George did a fine job of demonstrating this aspect of exception ... to also be in Partition I.12.4.2.5, the overview of Exception Handling. ... filter block - is this true only for inline code, ... nested exception the new exception would have to walk the stack anyway from ...
    (microsoft.public.dotnet.framework.clr)