|
>>>>>>>>>>>>>>>>
I'm not sure why they chose to do this, but it does look intentional.
My
only guess so far is that they wanted to allow developers the opportunity to inspect the program's state with a debugger before any of the finally blocks ran. <<<<<<<<<<<<<<<< That, and the fact that having a "two-pass" stack
walk matches Windows' SEH better than the single pass you suggest with finally
clauses invoked as you go. In fact, I'm not even sure how the single pass would
work in Mono in the presence of user-filtered handlers. (The way I read the
specification, user-filtered
handlers must run before any finally block is being run.
Moreover, in a future release they seem to intend to support EXCEPTION_CONTINUE_EXECUTION returned from filters which would *require*
the stack to be intact.)
My 2c anyway
Cristian
|
- RE: [Mono-list] RFC: Corlib Unit Test on Linux Ho... Nick Drochak
- RE: [Mono-list] RFC: Corlib Unit Test on Linu... Linus Upson
- RE: [Mono-list] RFC: Corlib Unit Test on ... Dietmar Maurer
- Re: [Mono-list] RFC: Corlib Unit Test... Charles Wiltgen
- RE: [Mono-list] RFC: Corlib Unit... Martijn Stegeman
- RE: [Mono-list] RFC: Corlib ... Linus Upson
- Re: [Mono-list] RFC: Corlib Unit Test on ... Paolo Molaro
- SV: [Mono-list] RFC: Corlib Unit Test on Linux How-To Patrik Torstensson
- Re: SV: [Mono-list] RFC: Corlib Unit Test on Linu... Paolo Molaro
- RE: [Mono-list] RFC: Corlib Unit Test on Linux How-To A Rafael D Teixeira
- Cristian Diaconu
