The Right Approach to Exceptions

[H. S. Teoh]

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 address_is at invalid.invalid 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.