Re: [boost] [review] Review of Exception begins today

From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2007-09-30 10:59:56

>      * What is your evaluation of the design?

I'm not keen on the use of operator<< to add the data to the exceptions.

<< has two existing meanings, left-shift and formatted output.  Note 
that the standard library does not use << for operations like 
push_back() and insert().  Adding another meaning here is not helpful.

For example, it's common for exceptions to have human-readable 
formatted content.  A user seeing code that uses operator<< on an 
exception might easily imagine that this is doing formatted output, and 
think "cool! I can do formatted output to this exception!", and write:

   catch (some_exception& E) {
     E << " while frobinacting at warp level " << warp_level;
     throw;
   }

Of course this isn't going to work.  If your code used a more 
conventional syntax, e.g.

   E.add_info<errno_tag>(errno);

then this confusion would be avoided.  (And I think it could be more 
concise too.)

Is "exception" the best choice of name for this library?  The name 
boost::exception might give the impression that it's the base class for 
all Boost exceptions, which is not the case; I might accidentlally write

   catch (boost::exception& E) {
     cerr << "got an exception from Boost: .....";

Also, there's the possibility that someone might propose some other 
exception-related library, orthogonal to this one, in the future.  How 
about "tagged_exception"?

>      * What is your evaluation of the implementation?

I haven't looked at the code.

>      * What is your evaluation of the documentation?

Good.

You might like to say something about the overhead that is added, i.e. 
that there is a std::list<something> in each exception (or whatever).  
(Remember that there are still plenty of people who dislike exceptions 
because of the perceived overhead that they involve.)

I think you do say something about the exception guarantee, but it 
might be useful to add a more explicit section near the start 
describing the exception guarantee and also whether any dynamic memory 
allocation is involved; what happens if the exception that was thrown 
was "out of memory"?

>      * Did you try to use the library?  With what compiler?

No.

>      * How much effort did you put into your evaluation?

About an hour reading the docs and preparing this message.

>      * Are you knowledgeable about the problem domain?

I have previously considered the problem of storing errno and a 
filename in an exception and have my own non-generic solution.

>      * Do you think the library should be accepted as a Boost library?

Only if operator<< is replaced.

Regards,

Phil.