The Right Approach to Exceptions

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Sun Feb 19 12:44:42 PST 2012


On 2/19/12 11:48 AM, Timon Gehr wrote:
> On 02/19/2012 05:00 PM, Andrei Alexandrescu wrote:
>> On 2/19/12 3:17 AM, Jonathan M Davis wrote:
>>> "As much information as possible" is way more than a transient
>>> property. If my
>>> code is going to retry or do something else or give up, it needs enough
>>> information to know what went wrong, not just whether the function
>>> which was
>>> called think it might work on a second try.
>>>
>>> Having an exception hierarchy provides some of that information simply
>>> with
>>> the types, and makes it easier to organize code based on what went
>>> wrong (e.g.
>>> separate catch blocks for each type of exception). And having that
>>> hierarchy
>>> also means that the derived types can have additional information
>>> beyond their
>>> type which could be useful but is specific to that problem and so
>>> wouldn't make
>>> sense on a general exception type.
>>>
>>> I really don't see what transient buys you in comparison to that.
>>
>> A notion of transiency planted fundamentally in all exceptions allows
>> one to act on it regardless of origin and hierarchy.
>>
>> Andrei
>>
>
> Transiency is a powerful concept at the handler side, but the interface
> it is difficult to fulfil at the point where the actual error occurs.
> What is important is probably not whether or not transiency is useful if
> it is there, but more whether or not a sufficient part of the useful
> exceptions are naturally transient. This is what I doubt. OTOH, as I
> understand it, introducing the concept would require additional
> boilerplate in most exception handlers.

I'm thinking of simply adding

@property transient() const pure { return false; }

to the base exception class. Most exceptions are not transient.


Andrei


More information about the Digitalmars-d mailing list