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
