I see exactly what you mean here.
I guess that any implementation that interrupts the first pass of the SEH
(the filtering) for whatever reason (event if it stores the exception and
rethrows it later like yours does) will suffer from this "handler
inversion" problem.
I haven't seriously thought it too far, but my instinct was to use the fs:
[0] chain just to trap the EE exception without interrupting it's normal
flow and to handle the managed "finally" blocks on the second pass
(unwinding) - if it wasn't handled by the first pass/global handler first.
I didn't put enough time in the idea so I won't even claim it works. (And
it certainly doesn't fit easily into the PAL's SEH macro handling
infrastructure so it's not actionable in the short run anyway.)
At any rate, it seems to me that the solution you included here would work
better than the current code without sacrificing portability, so it's
worth having.
Thanks for your time
Cristian
On Wed, 1 May 2002 12:17:07 -0700, Jan Kotas <[EMAIL PROTECTED]> wrote:
>Yes, it is the comment I was referring to.
>
>
>On the ordering differences:
>
>Assume that the implementation of PAL_LocalFilter wrapper will be doing
>catch & rethrow. I can't think of any other implementation at the moment
>that preserves the SEH interop. Something like:
>
>MyDelegateFilter(...)
>{
> exception_thrown = true;
> <store the exception info>
> return EXCEPTION_EXECUTE_HANDLER;
>}
>
>MyDelegateWrapperHelper(...)
>{
> PAL_TRY {
> MyDelegate(...);
> } PAL_EXCEPT_FILTER(MyDelegateFilter, ...) {
> }
> PAL_ENDTRY
>}
>
>MyDelegateWrapper(...)
>{
> <pack all parameters into myparams>
>
> PAL_LocalFilter(MydelegatewrapperHelper, &myparams);
>
> if (exception_thrown) {
> // rethrow the exception
> RaiseException(<stored exception info>);
> }
>}
>
>In your example, things will be executed in the following order with
>this solution:
>
>- C throws exception
>- C finally block is executed
>- B filter is executed
>- B handler is executed
>- execution continues without any exception back into A
>
>To compare, things should be executed in the following order on .NET
>Framework:
>
>- C throws exception
>- B filter is executed
>- C finally block is executed
>- B handler is executed
>- execution continues without any exception back into A
>
>
>-Jan
>
>This posting is provided "AS IS" with no warranties, and confers no
>rights.
>
