"Emil Dotchevski" wrote:
1. The ability to copy the contained info in one boost::exception to another boost::exception, for folks like you who want to translate exceptions. I could support the following syntax:
class my_exception: public boost::exception { }; class translated_exception: public boost::exception { };
catch( my_exception & x ) { throw translated_exception() << x; }
I see problem that common tags (like file/line) from the old exception may overwrite tags in the new one (or vice versa). A semi-standardized tag "previous_exception" may be better here: catch( low_level_exception& e) { throw high_level_exception() ... << exception_info<boost::exception_tag::previous>(e); } This could also make the text dumps more structured.
2. The ability to dump all info stored in boost::exception objects, for debugging purposes. Something like:
boost::exception & x;
std::string info( x.what() ); //get a string of all info stored in boost::exception.
Is this alright? Does anyone still think that it is necessary to support enumeration of the info contained in boost::exception?
IMHO the dump is enough. Without reflection the enumeration is not of much use. ----------- A helper for capturing stack trace may come handy. Say: void foo() { throw boost::exception() << .... } void foo1() { try { foo(); } catch (boost::exception& e) { e.add_stack_trace(BOOST_CURRENT_FUNCTION); throw; } } void foo2() { try { foo1(); } catch (boost::exception& e) { e.add_stack_trace(BOOST_CURRENT_FUNCTION); throw; } } Inside would be list of const char* pointers. The main advantage would be easy to type syntax - no need to check prior existence of the data or anything else, just a single line. The debugging text dump may know about it and pretty print the stack. If the ability to chain exception is standardized then the individual sub-stack traces may get merged when printed. Functions may be even written as void foo() try { ... } catch (boost::exception& e) { e.add_stack_trace(BOOST_CURRENT_FUNCTION); throw; } i.e. no outer brackets. Some compilers do not emit any code for the "try" so it may end up more efficient than classical stack-trace via a macro on the top of function body. /Pavel