Re: [boost] [review] Exception - result

From: John Torjo (john.groups_at_[hidden])
Date: 2007-11-09 11:00:08

Congrats!
I'm glad it made it, and sorry for not having time to do a thorough review.

Best,
John
> I'm pleased to announce that the Exception library has been accepted 
> into boost. Thanks to all formal and informal reviewers and to Emil 
> Dotchevski for the library!
>
>
> Summary of possible improvements:
> =================================
>
>
> Design
> ------
>
> Nearly all reviewers made suggestions for syntactic improvements. The 
> "tag(value) syntax" (as suggested by John Torjo) for instance provides 
> sufficient syntactic sugar and seems lightweight to implement.
>
> Suggested features in this area are (those are implementable on top of 
> the current design - but will keep users from reinventing the wheel if 
> provided by the library):
> - Support for grouping information, and
> - support for generating stack traces.
>
> I personally still have a bad feeling about 'enable_error_info' - let's 
> just revisit and discuss it on the list before changing 
> boost::throw_exception.
>
> The related discussions about clone/rethrow support is still ongoing.
>
>
> Documentation
> -------------
>
> Best practices for the catch-site should be clarified in the documentation.
>
> Same goes for using the same tag multiple types with one exception object.
>
> Other comments should be addressed (I won't put much energy into 
> summarizing documentation comments, guessing most of them might have 
> been taken care of, already).
>
>
> Deployment
> ----------
>
> There was a suggestion (from Pavel Vozenilek) to put #ifdef around the 
> code of boost::exception that could be put into a separate translation 
> unit. There should probably also be a 'build' directory and a Jamfile so 
> there is smooth integration with the Boost build system.
>
> Of course, Jamfiles for test/examples should be added.
>
>
> Implementation
> --------------
>
> Several reviewers noted that the library is rather allocation-heavy. It 
> pretty much comes down to shared_ptr overuse (causing many unnecessary 
> allocations of small objects and synchronized instructions to be 
> executed) though not in performance critical code possibly affecting 
> other threads and future allocations.
>
>
> --
> Tobias Schwinger
> - Review Manager -
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>
>   

-- 
http://John.Torjo.com -- C++ expert
... call me only if you want things done right