The Right Approach to Exceptions

Andrei Alexandrescu SeeWebsiteForEmail at
Sun Feb 19 08:29:51 PST 2012

On 2/19/12 9:56 AM, Nick Sabalausky wrote:
> "Andrei Alexandrescu"<SeeWebsiteForEmail at>  wrote in message
> news:jhr0vq$24t0$1 at
>> On 2/19/12 5:22 AM, deadalnix wrote:
>>> Le 19/02/2012 08:05, Andrei Alexandrescu a écrit :
>>>> How about a system in which you can say whether an exception is I/O
>>>> related, network related, recoverable or not, should be displayed to the
>>>> user or not, etc. Such is difficult to represent with inheritance alone.
>>> That may sound great on the paper, but it isn't. The fact that an
>>> exception is recoverable or not depend often on your program and not on
>>> the cause of the exception.
>> This is self-evident. Again, the meaning of "recoverable" is "operation
>> may succeed if retried with the same input". It's a hint for the catch
>> code. Of course the program is free to ignore that aspect, retry a number
>> of times, log, display user feedback, and so on. But as far as definition
>> goes the notion is cut and dried.
> WTF? "Recoverable" means "can be recovered from". Period. The term doesn't
> have a damn thing to do with "how", even in the context of exceptions. It
> *never* has. If you meant it as "operation may succeed if retried with the
> same input", then fine, but don't pretend that *your* arbitrary definition
> is "cut and dried".

I think it's a reasonable definition of "can be recovered from" in the 
context of exceptions.


More information about the Digitalmars-d mailing list