The Right Approach to Exceptions

[Andrei Alexandrescu]

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 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)?

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