On Mon, Aug 10, 2009 at 1:28 AM, Gennadiy Rozental
Emil Dotchevski
writes: I want to have a bit more flexibility as to what and how I print. I'll need to get a hold of each component separately.
Reporting unexpected exceptions by a testing framework is pretty much perfect use case for boost::current_exception_diagnostic_information; if the data in the returned string is not sufficient for diagnostic purposes, then the function itself should be modified to return a better string.
The data probably is sufficient. I just want to format it differently (and in different place) and more importantly I want to allow users to format it as they please.
If the exception is expected, then you can probe it for various data you know it might contain using boost::get_error_info. Diagnostic_information is used when you catch an exception you know nothing about which might contain any type and any number of data useful for diagnostic purposes. How would the user format something like this?
Since the testing framework wouldn't know anything about the exception it's reporting, it should catch(...) and leave it up to current_exception_diagnostic_information to provide all the information it can dig out from whatever the current exception may be.
1. It will never get to the catch(...) execution monitor has tons of other catch clauses (including catch (std::exception)) which will trigger first.
So you could do: catch( foo & e ) { //do other stuff, and then: std::cerr << boost::diagnostic_information(e); } catch( boost::exception & e ) { //do other stuff, then: std::cerr << boost::diagnostic_information(e); } catch( std::exception & e ) { //do other stuff furst, then: std::cerr << boost::diagnostic_information(e); } catch( ... ) { std::cerr << boost::current_exception_diagnostic_information(); }
2. execution monitor is very careful about memory being used. How about diagnostic_information?
You'd have to define the meaning of 'careful' :) but if you're asking how much memory diagnostic_information allocates, it simply composes a std::string which it returns to the caller.
3. I pretty much only need file, line and function name. Are you saying I can't do what you are doing inside diagnostic information to get a hold of them?
If the exception was thrown by BOOST_THROW_EXCEPTION, then yes you'd have file, line and function name. However, objects that derive from boost::exception can have data of arbitrary type, some of it added at the point of the throw, some of it added later (meaning, it depends on the callers of the function that throws.) Do you not want to display all that information when you catch a user exception in the testing framework? Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode