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