Emil Dotchevski
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?
Every exception has a point of inception. This is the info I'd like to get my hands on. These can be reported in XML, human readable and any other format user may opt to implement.
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); }
1. Isn't supposed to be other way around: first catch boost::exception, followed by catch foo? I'd prefer to have boost:exception related logic in a single catch clause instead of being spread between 20. 2. I do not want to print anything. I collect information and return it (by throwing another exception) to the higher level, which in turn decides how and where to report it.
catch( std::exception & e ) { //do other stuff furst, then: std::cerr << boost::diagnostic_information(e); } catch( ... ) { std::cerr << boost::current_exception_diagnostic_information(); }
What is the point of trying to dig something here? Wouldn't the boost::exception based exception will always be caught in 'catch boost::exception' clause above?
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.
execution_monitor does not allocate memory at all in the point of error processing.
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.
Ok. So how do I do this?
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?
I do not mind if method 'what' would generate "rich" error message including everything, but the information about the point of inception (Or some other method) Gennadiy