On Sun, Feb 19, 2012 at 05:38:23PM -0600, Andrei Alexandrescu wrote: > On 2/19/12 5:28 PM, Jonathan M Davis wrote: > >On Sunday, February 19, 2012 18:48:02 [email protected] wrote: > >>I guess "transient" is more descriptive. > > > >Actually, thinking on it some more, I don't think that transient will work at > >all, and the reason is simple. _Which_ operation should you retry? > > The application decides. > > >You don't even necessarily know which function the exception came > >from out of the functions that you called within the try block - let > >alone which function actually threw the exception. Maybe it was > >thrown 3 functions deep from the function that you called, and while > >retrying that specific call 3 functions down might have made sense, > >retrying the function 3 functions up doesn't necessarily make sense > >at all. > > > >Whether or not you can retry or retrying makes any sense at all is > >_highly_ dependent on who actually catches the exception. In many > >cases, it may be a function which could retry it, but in many it > >won't be, and so having the exception tell the caller that it could > >retry would just be misleading. > > No dependence on context. The bit simply tells you "operation has > failed, but due to a transitory matter". That is information local to > the thrower. [...]
But *which* transitory matter? A temporary outage on the network? A timeout due to excessive CPU load? A full disk (which is transitory because some other process might remove a large file in the interim)? Without knowing the context, this information is of little use. I'm really starting to like the Lisp system more, the more I think about this. Let the low-level code provide a list of recovery strategies, and let the high-level code register recovery policies that select between these recovery strategies *in the context of the low-level code*. The runtime matches policy to strategy, and the stack is only unwound when no recovery is possible. T -- Frank disagreement binds closer than feigned agreement.
