From: Edward Diener (eddielee_at_[hidden])
Date: 2003-04-26 19:06:00
David Abrahams wrote:
> "Edward Diener" <eddielee_at_[hidden]> writes:
>>> I browsed the article (I confess to not having read everything, so
>>> please correct any misapprehensions). My sense is that the
>>> is oriented towards detecting programmer errors and responding via
>>> an exception.
>> I don't think ENFORCE is oriented toward that at all. There's no
>> orientation involved other than to throw an exception based on a
>> condition. I agree with you that direct programming errors should
>> generally not throw exceptions but should ASSERT so that the
>> programmer can fix the error. However I don't think ENFORCE has
>> anything to do with this debate about when to ASSERT and when to
>> throw exceptions. Perhaps the examples give the impression which you
> I think so.
>> but I think the problem is just choosing better examples in which
>> one would want to throw an exception and not a technical issue as to
>> the benefits of using ENFORCE in order to simplify exception
> Can you show me a better example? This is not a challenge. Really,
> if this ENFORCE idea is a useful one I want to understand it.
A typical example might be a 3rd party library in which an end-user passes a
std::string, call it "s", which must contain some valid data and not be
empty. In this case I would throw an exception since it is not my error but
my end-user's error. Say my exception, derived from std::runtime_error is
eSomeEmptyString. I could then write:
To me this is a nice shorthand notation for throwing an exception when the
"s" string is empty, ie. contains no data.
I believe Mr. Alexandrescu developed Enforce as a nice way of regularizing
the code when an exception must be thrown based on a condition. The code
becomes more readable and easier to understand. For me such constructs,
although not revolutionary in and of themselves, are important in making
cleaner and more understandable coding and I appreciate Mr. Alexandrescu's
efforts in such an area.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk