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? Regards, Rodrigo

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.

Exactly. And most of us had to create such classes. As we did for Sockets before Boost Asio.

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.)

When you define standard exceptions, coders everywhere will get the idea of what an exception actually means just by looking at it (think std::bad_alloc()). It will help improve standards in the language by providing a tool that everyone can benefit from. If you don't have an exception hierarchy in your programs, chances are you are not taking full advantage of exception handling. What can be done in this matter for Boost? Until then I'll have to continue using a library meant specifically to hold my exception hierarchy. Regards, Rodrigo

Something that confuses me a little in the exception documentation is the struct tag used when typedef'ing error_info<>. It's unclear if these tags are coming from boost exception headers, std headers (like the in the case below) or if these must be explicitly defined by the user, or if the simple fact that of using them in the typedef is enough to declare them.

typedef boost::error_info std_range_min;

So the above is equivalent to the below?

struct tag_std_range_min; typedef boost::error_info std_range_min;

It may not be obvious to everyone ;-)  Wasn't to me at first.  Thanks, --DD

I'm certainly not an expert on boost::exception (just started integrating it into my project a few days ago), but it appears to me that the purpose is twofold: -You can easily have multiple error_info objects which hold the same type of data, but for different purposes. Say for example a file loading error, where you want to report the filename and a description of the error in two seperate error_info's; using the struct type as a template parameter gives you a way to easily distinguish between them. -It allows you to describe the information the error_info contains once, when you declare the struct in the typedef. Saves you from having to type in the info every time you use a particular error_info Hope that helps, MC