|
Boost : |
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2006-06-22 12:40:49
> Emil Dotchevski wrote:
>> catch( read_error & x )
>> {
>> if( info * xi = dynamic_cast<info *>(&x) )
>
> you do not need dynamic_cast here, or you could just put
> catch(info& x)
> above read_error?
If your program is somewhat simple, you may be tempted to catch(info&), and
then show the user everything you could dig out of the info object. But do
you really not care what went wrong? Typically you do. For example, if you
catch(render_error&) you wouldn't be probing the info sub-object for file
names, would you?
I think how you catch your exceptions should remain unchanged even if you
begin using the presented exception lib. The exceptions you throw using the
'failed' function template are still part of the exception class hierarchy
you have in your program. The only thing that changes is that you can clean
your exception class hierarchy from all types that don't indicate a class of
errors, but instead serve as holders of additional information.
The dynamic_cast also makes it easier to roll the exception lib into
existing code. You can start converting your throws from throw my_error() to
throw failed<my_error>(). Meanwhile, you still catch(my_error&), so that
regardless of how you throw, you will handle the exception correctly.
--Emil
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk