On Tue, Mar 31, 2009 at 7:30 PM, Rodrigo Madera
I added a Motivation page and a few other tweaks in the documentation.
This is a really good contribution. I've had my own share of motivation troubles when deciding to modify my in-house exceptions to be Boostified.
Now that I mention it, is there any interest of the crowd to have common problems modeled as ready-to-use exceptions?
For example, file not found, access denied, not found (the base for xxx not found), etc. These would be like standard building blocks for new implementations. WDYT?
Certainly, if exception types have no members -- which is enabled by deriving from boost::exception -- there is no need for various libraries to define their own file_not_found exceptions; a single boost::exceptions::file_not_found would be sufficient for all use cases. As you're suggesting, standardizing exception types with more abstract semantics, such as a generic "item not found" type also seems logical. I had the same idea: I do have an item_not_found exception, which is the base of things like file_not_found, factory_not_found, type_not_found, etc. But in my own experience -- for what it's worth -- I've never needed to catch the generic item_not_found type (of course there's no harm in having that ability.) Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode