The Right Approach to Exceptions

Jacob Carlborg doob at
Sun Feb 19 08:43:39 PST 2012

On 2012-02-19 17:29, Andrei Alexandrescu wrote:
> 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.

No it's not. Say you want to save a file. You're saving it in "/" which 
you don't have permission to write to. The system throws an exception 
PermissionException, this is a recoverable exception since the 
application could prompt the user to save the file in a different location.

/Jacob Carlborg

More information about the Digitalmars-d mailing list