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