[boost] Re: Re: ENFORCE

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
>>> technique
>>> 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
>> have
>
> 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
>> throwing.
>
> 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:

Enforce<eSomeEmptyString>(!s.empty(),"My Message");

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.