On 2/19/12 7:58 PM, H. S. Teoh wrote:
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)?
Doesn't matter.
Without knowing the context, this information is of little use.
It is. User code may decide to retry the high-level operation (of which
the low-level failure has no knowledge).
Andrei
