I'm investigating boost exception to see if it is helpful in a particular instance. I start by looking at the first Tutorial. I can't see how this is better than struc my_error : public std::exception { int m_ errno; my_error(int errno) : m_errno(errno) {} }; ... throw my_error(errno) try { ... } catch(my_error e){ cerr << e; } What am I missing here? This first example is two compilicated in that it requires that I delve into a bunch of other stuff (operator << for exception data?) and it doesn't provide any motivation. I think it would be more useful if it "spoon fed" the reader (me in this case) a little more. Something like: Traditional simple example like that above. explanation of why the example isn't "good enough" simple example reformulated using boost exception explanation of how this addresses the short comings of the original version. I think this would motivate more users to transition to the library. Robert Ramey
On Sun, Mar 29, 2009 at 11:25 AM, Robert Ramey <ramey@rrsd.com> wrote:
I'm investigating boost exception to see if it is helpful in a particular instance. I start by looking at the first Tutorial.
I can't see how this is better than
struc my_error : public std::exception { int m_ errno; my_error(int errno) : m_errno(errno) {} };
... throw my_error(errno)
try { ... } catch(my_error e){ cerr << e; }
What am I missing here? This first example is two compilicated in that it requires that I delve into a bunch of other stuff (operator << for exception data?) and it doesn't provide any motivation. I think it would be more useful if it "spoon fed" the reader (me in this case) a little more. Something like:
Traditional simple example like that above. explanation of why the example isn't "good enough" simple example reformulated using boost exception explanation of how this addresses the short comings of the original version.
Now that you point it out, I realize that this type of example is necessary. I'll add it to the documentation for 1.39. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
On Sun, Mar 29, 2009 at 11:25 AM, Robert Ramey <ramey@rrsd.com> wrote:
I'm investigating boost exception to see if it is helpful in a particular instance. I start by looking at the first Tutorial.
I can't see how this is better than
struc my_error : public std::exception { int m_ errno; my_error(int errno) : m_errno(errno) {} };
... throw my_error(errno)
try { ... } catch(my_error e){ cerr << e; }
What am I missing here? This first example is two compilicated in that it requires that I delve into a bunch of other stuff (operator << for exception data?) and it doesn't provide any motivation. I think it would be more useful if it "spoon fed" the reader (me in this case) a little more. Something like:
Traditional simple example like that above. explanation of why the example isn't "good enough" simple example reformulated using boost exception explanation of how this addresses the short comings of the original version.
I think this would motivate more users to transition to the library.
I added a Motivation page and a few other tweaks in the documentation. It'll be out with the 1.39 release but can be viewed right away through this link: http://svn.boost.org/svn/boost/trunk/libs/exception/doc/motivation.html Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
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
On Tue, Mar 31, 2009 at 7:30 PM, Rodrigo Madera <rodrigo.madera@gmail.com> wrote:
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
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
On Tue, Mar 31, 2009 at 5:25 PM, Emil Dotchevski <emildotchevski@gmail.com> wrote:
I added a Motivation page and a few other tweaks in the documentation. It'll be out with the 1.39 release but can be viewed right away through this link: http://svn.boost.org/svn/boost/trunk/libs/exception/doc/motivation.html
Thanks for that Emil, it's helpful to me too. 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<struct tag_std_range_min,size_t> std_range_min; So the above is equivalent to the below? struct tag_std_range_min; typedef boost::error_info<tag_std_range_min,size_t> std_range_min; It may not be obvious to everyone ;-) Wasn't to me at first. Thanks, --DD
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<struct tag_std_range_min,size_t> std_range_min;
So the above is equivalent to the below?
struct tag_std_range_min; typedef boost::error_info<tag_std_range_min,size_t> 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
participants (5)
-
Dominique Devienne -
Emil Dotchevski -
Michael Crawford -
Robert Ramey -
Rodrigo Madera