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++
_______________________________________________
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
