On 7/15/07, Thomas Lord <lord at emf.net> wrote:
>
> 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".
>
:-).
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:
>
:-). And I don't usually use dynamically scoped exception handlers. I much
prefer to pass in a function to handle error conditions. Though, I figure if
I'm going to back a spec, I should be comfortable with all of it.
Example of continuable: Virtual Memory Page Faults!
>
Got it. So, this is a case where exceptions are being more or less used to
communicate a circumstance.
and, example of non-continuable: Virtual Memory Illegal Address References
>
Again, got it. Thanks. These cases seem fairly clear.
Now, what about a higher level case - something like I originally
mentioned. You go to open a DB connection, and it fails. Is the raise
continuable or not? I'm not trying to be difficult here, I'm honestly not
sure which type it should be.
Thanks,
Ben
--
Ben Simon
My blog: http://benjisimon.blogspot.com
tenspotting.com - Top 10 Lists++
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.r6rs.org/pipermail/r6rs-discuss/attachments/20070715/7ad081ae/attachment.htm
Received on Sun Jul 15 2007 - 22:55:03 UTC