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