[r6rs-discuss] r6rs-discuss Digest, Vol 11, Issue 13

From: Jason Orendorff <jason.orendorff>
Date: Mon, 16 Jul 2007 09:34:55 -0400

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.

She can, of course, just say "non-continuable" and think no more of it,
which is less work. If the caller wants to handle errors by retrying or by
trying something different, he must do it himself.

On the other hand, the open-db author can do some extra design work
and decide what the continuation of a connection failure should mean,
and implement that. She might decide it expects the handler to pass
back a retry strategy, like '(retry-with ((timeout 1000))).

If the open-db author doesn't think about what the continuation of an error
should be, then continuing from that error is Bad. It will very likely break
the programmer's logic about how the code is supposed to work. It could
cause code after the (raise) to execute with important things undone, or
variables not properly initialized--or initialized to values perhaps
maliciously chosen by the error handler!

(raise) stops that nonsense.

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.

Cheers,
-j
Received on Mon Jul 16 2007 - 09:34:55 UTC