Re: [boost] ENFORCE

From: David Abrahams (dave_at_[hidden])
Date: 2003-04-26 11:35:03

"Andrei Alexandrescu" <andrewalex_at_[hidden]> writes:

> By the way, I believe what would be more interesting for Boost is the
> recent article (http://www.cuj.com/experts/2106/alexandr.htm), written by
> Petru Marginean and myself. (Warning - the article has recently been
> updated.)
>
> We have good experience in reducing source code size by using enforcements.
> There are a number of interesting techniques used out there, and I believe
> ENFORCE would be quite useful as a Boost library.

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've always had a philosophical problem with that idea.
In C++, unlike in strongly-/dynamically-typed languages, exceptions
seem very different from assertions, and are usually a bad way to
handle programmer errors.  I'll try to articulate why I feel this way:

  0. See "what about programmer errors?" at
     http://www.boost.org/more/error_handling.html, which is a good
     start.  [Also see notes about exception messages while you're
     there]

  1. Programmers should not have lingering doubts about whether their
     correctness checks are going to slow their code down or make it
     bigger in release mode, so they should almost always be compiled
     away.

  2. When programmers get used to using an exception-throwing thing in
     place of assert (or some suitable replacement), they will tend to
     put these things in code regions that should be nothrow.

  3. The use of checks like this foster a false sense of security; it
     becomes "OK to make mistakes", because the error checks will find
     them and throw a runtime_error exception.

I'll be the first to admit that these ideas are not based on any
experience having worked with systems that use programmer-generated
exceptions for runtime errors (except at SDK interface boundaries,
when the SDK is the shipped product); they're just based in the way I
think about programming and exception-handling.

BTW, this:

     Enforce(cout) << 
         Enforce(auto_ptr(MakeWidget()))->ToString();

Doesn't actually compile, assuming you mean "auto_ptr<Widget>":

"ComeauTest.c", line 6: error: class "std::auto_ptr<Widget>" has no suitable copy
          constructor

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com