Ben Simon wrote:
>
> Thanks for the quick feedback. Sorry to be so thick on this, but I'm
> still not seeing it.
>
Oh, don't feel that way. It's an "obvious after you see it (usually by
being shown it) thing".
>
> When I write code that throws an exception, I don't think: "is this
> continuable or not," I think "this has to fail, let someone else deal
> with it." I guess it boils down to the fact that I don't see why an
> exception isn't always continuable depending on how clever the handler
> wants to be.
>
> Perhaps you can provide an example of a continuable and
> non-continuable circumstances? That would probably clear things up.
Well, personally, I don't think dynamically scoped error handlers are a
good idea at all and I think there's almost always a better way to code
applications that want to use exceptions for non-error purposes. So,
you're asking me explain the design logic of features I don't think make
a lot of sense -- but, hey, I can do that:
Example of continuable: Virtual Memory Page Faults!
One of the primitive operations in a typical OS kernel like Linux is
"give some cycles to process X". One of the exceptions that primitive
can raise is "Oops -- X tried to access a virtual page of memory that
isn't mapped!". The kernel treats that as a continuable exception:
it brings the demanded page into the virtual memory system and then
retries the instruction that raised the exception.
and, example of non-continuable: Virtual Memory Illegal Address References
Illegal address references, on the other hand, don't continue (normally)
-- they non-locally exit back to the parent process.
-t
>
> Thanks,
> Ben
>
> --
> Ben Simon
> My blog: http://benjisimon.blogspot.com
> tenspotting.com <http://tenspotting.com> - Top 10 Lists++
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.r6rs.org/pipermail/r6rs-discuss/attachments/20070715/9d1335eb/attachment.htm
Received on Sun Jul 15 2007 - 23:01:07 UTC