On 7/16/07, Jason Orendorff <jason.orendorff at gmail.com> wrote:
>
> Ben Simon wrote:
> > 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.
>
> The author of the open-db procedure has to decide.
> ...[useful explanation trimmed]
> When you read code, (raise) and (raise-continuable) will mean different
> things. (raise) never returns. (raise-continuable) behaves more like an
> ordinary procedure: you write your code as though it will return, though
> it might not. This communicative purpose alone is convincing to me.
>
OK, I think I got it. Thanks Jason and Thomas for walking me through this.
In the end, after a night of sleep, I think my own example provides a clear
argument for why we need raise vs. raise-continuable.
[for the sake of it being in this thread, here's the example:]
(define (open-db-connection host port username password)
(let ((raw-tcp-conn (open-tcp-connection host port)))
(if (not raw-tcp-conn)
(raise "Unable to open db connection")) ;; coming back here, useless
(authenticate-connection raw-tcp-conn username password)))
As Jason eluded to, the way I wrote the above cod returning from the
handler wouldn't actually do any good as raw-tcp-conn would remain #f. I
would have needed to specifically written the code to make returning back to
the raise point meaningful. So, if I'm going to write fancy code to support
continuing the computation, then the least I can do is mark that code
clearly with a raise-continuable vs raise procedure call.
It's official, I'm a believer.
-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/20070716/ba67f498/attachment.htm
Received on Mon Jul 16 2007 - 09:55:16 UTC