My lesson for today

After sveral hours in debugger and lot's of head scratching, I have decided
that I will have to write in my Dolphin notebook the following sentence 100
times:

"Ensure blocks are executed after _all_ exception handlers."

rush
--
http://www.templatetamer.com/
http://www.folderscavenger.com/

Rush,

> After sveral hours in debugger and lot's of head scratching, I have decided
> that I will have to write in my Dolphin notebook the following sentence 100
> times:
>
> "Ensure blocks are executed after _all_ exception handlers."

Ok, I'll bite :)  I have always thought of #ensure: as being the last
thing a thread does, and IIRC, the VM temporarily restarts it if
necessary to run the code on the correct thread.  Looking at it that
way, your lesson strikes me as a natural outcome.  Am I missing something?

Have a good one,

Bill


--
Wilhelm K. Schwab, Ph.D.
[hidden email]

"Bill Schwab" <[hidden email]> wrote in message
news:dgp5rq$18jg$[hidden email]...
> Ok, I'll bite :)  I have always thought of #ensure: as being the last
> thing a thread does, and IIRC, the VM temporarily restarts it if
> necessary to run the code on the correct thread.  Looking at it that
> way, your lesson strikes me as a natural outcome.  Am I missing something?

It was me who had been missing something :)  My mental image was that ensure
just gets executed moment you get out of the block either normaly, or by
exception, and in that image if ensure was nested inside exception handler,
it would surely be executed before exception handler. Yeah right.

The way they actually behave (as you and RTF Manual explain), is when thread
is at end and all exception handlers had their job done. It actually makes
much more sense, since exceptions could be restarted or ignored, and what
would happen if you ignore one, and restart the code, but inner ensure had
allready closed the file this code counts on.

rush
--
http://www.templatetamer.com/
http://www.folderscavenger.com/

rush wrote:

>  My mental image was that
> ensure just gets executed moment you get out of the block either normaly,
> or by exception, and in that image if ensure was nested inside exception
> handler, it would surely be executed before exception handler.

I don't know if this will help any, but your picture wasn't far wrong.  Not
wrong at all in fact, except for one thing -- when the exception handler is
invoked, you haven't /yet/ left the block.  If you set a handler, then the
handler code will be executed as if it had been invoked at the point where the
signal was thown.

That's different from the way that (say) C++ and Java work, where the system
first unwinds the stack back to where the handler was set and only then invokes
the handler.

The good thing about that is that you can have resumable exceptions (very
useful in some circumstances).  The downside is that setting an exception
handler can't be made entirely free[*] (some code always has to execute even if
the exception is never thrown) unlike Java where using a try/catch block has
zero runtime overhead unless the exception is actually thrown.

    -- chris

([*]  unless the implementation is pretty sophisticated)