On 7/15/07, Thomas Lord <[EMAIL PROTECTED]> 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++
_______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
