On Sun, Aug 9, 2009 at 1:27 PM, Gennadiy Rozental wrote:

Emil Dotchevski writes:

...

I'm not familiar with the test runner, but assuming that it is written in C++, all it needs is something like:

#include ....

catch(...) {   std::cerr << boost::current_exception_diagnostic_information(); }

This will print the what() message (if available) too.

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. I welcome patches (including platform-specific hacks) that would provide more useful diagnostic information about exceptions.

Also I want to catch boost::exception by specific clause. It should be fine, right? Will I need to place it first in my list of catch clauses? Cause AFAIK actual type will inherit both boost::exception and the exception type being thrown.

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. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

On Mon, Aug 10, 2009 at 1:28 AM, Gennadiy Rozental wrote:

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

On Mon, Aug 10, 2009 at 11:45 AM, Gennadiy Rozental wrote:

Emil Dotchevski writes:

...

...

...

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.

I was implying that you normally catch more specific exceptions first. If you don't care about foo in particular you can use a generic catch like catch(boost::exception/std::exception) or catch(...).

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.

I don't see the point of throwing another exception but if that's what you want to do then you could use boost::exception_ptr: catch(...) { BOOST_THROW_EXCEPTION(another_exception(boost::current_exception())); } Later on, when you catch(another_exception &), you can pass the stored exception_ptr to boost::diagnostic_information, and you'll get diagnostic information about the exception it holds (the one captured by boost::current_exception() in the original catch(...)). Or you can rethrow it and use suitable catches to handle 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?

If all you do is get diagnostic_information, then just the catch(...) is sufficient.

...

...

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.

In fact the act of throwing an exception allocates memory which comes from the heap in many implementations but anyway, I hope you're not proposing that diagnostic_information returns something other than a std::string :)

...

...

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?

Use get_error_info(e), get_error_info(e), get_error_info(e).

...

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)

The problem with what() is that some programmers use it to return a user-friendly message. This is incorrect because in general user-friendly messages have to be localized which clearly goes beyond what()'s interface. Boost::diagnostic_information has clearer semantics: the string it returns is not user-friendly; it has any and all information that might be useful for diagnostic purposes, which also includes the output from what(), the file/line/function information, anything added to a boost::exception through operator<<, etc. At BoostCon there was some interest in adding stack trace to boost::diagnostic_information too. In principle, anything that is known about the exception should be included. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

On Mon, Aug 10, 2009 at 2:58 PM, Gennadiy Rozental wrote:

Emil Dotchevski wrote:

...

I was implying that you normally catch more specific exceptions first. If you don't care about foo in particular you can use a generic catch like catch(boost::exception/std::exception) or catch(...).

I do. I hoped I can handle throw foo() in catch( foo ) and BOOST_THROW_EXCEPTION( foo() ) in catch( boost::exception ). Former would not try to dig inception point info. Later would.

Actually I might want to do it in all clauses after all. I do want to be as specific as possible. An alternative is to somehow deduce type at runtime in generic catch boost::exception clause, but this seems non reliable.

I might not be understanding exactly what you're doing. In my mind, a testing framework should assume that (unless you're testing exception handling) any exception a test emits is unexpected, and then the only useful thing you can do is log some diagnostic information; I don't see a need for anything more than catch(...) { std::cerr << boost::current_exception_diagnostic_information(); } Here is an example of what this could display: example_io.cpp(83): Throw in function class boost::shared_ptr<struct _iobuf> __cdecl my_fopen(const char *,const char *) Dynamic exception type: class boost::exception_detail::clone_impl<class fopen_error> std::exception::what: example_io error [struct errno_ *] = 2, OS says "No such file or directory" [struct file_name_ *] = tmp1.txt [struct function_ *] = fopen [struct open_mode_ *] = rb By the way in some IDEs double-clicking the first line in the above message will open the source location in the editor.

...

...

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.

I don't see the point of throwing another exception

I need to report the error somehow, don't I? Including all the details.

Yes, and in my mind "all the details" are included in the string returned by boost::current_exception_diagnostic_information. If anything useful is missing from that string, then it should be included instead of doing something else.

...

but if that's what you want to do then you could use boost::exception_ptr:

catch(...) {  BOOST_THROW_EXCEPTION(another_exception(boost::current_exception())); }

I do not see why I need BOOST_THROW_EXCEPTION. I do not care about this exception inception point. I know it ;) Also I throw this exception in all cases when an error occurred (for example in case if signal triggered). It operates on strings and numbers.

Sure, you can throw any exception without BOOST_THROW_EXCEPTION. However there's virtually no overhead in using BOOST_THROW_EXCEPTION. It does not allocate memory, yet allows users to add arbitrary data in the exception and to get a boost::exception_ptr to 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?

If all you do is get diagnostic_information, then just the catch(...) is sufficient.

But If I already have catch( boost::exception ) I should not try to dig this info in catch(...) right?

In this particular case, what would you do with a boost::exception that's different from what you'd do with any other exception in a catch(...)?

...

...

Ok. So how do I do this?

Use get_error_info(e), get_error_info(e), get_error_info(e).

What is the requirement on type of e? can it be char*? Or std::string?

e is the exception you catch. Here's how you use it: if( char const * const * f=get_error_info(e) ) { //*f is a char const * that points the file name string. } if( char const * const * f=get_error_info(e) ) { //*f is a char const * that points the function name. } if( int const * l=get_error_info(e) ) { //*l is the line number }

Can we have something like 'cause', which will be the same as diagnostic_info, but without inception point?

For what reason? It seems to me that you're trying to make the returned string "prettier" which is unrealistic. The string is pretty much guaranteed to be ugly to look at yet rather informative. :) That said, I do agree that especially if you're generating some kind of xml report, processing the location of the throw specifically is a good idea. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

On Mon, Aug 10, 2009 at 5:37 PM, Gennadiy Rozental wrote:

Does this require some kind of RTTI?

Some kind, yes, to provide type safety. If the built-in RTTI is disabled, Boost Exception uses the same workaround used by shared_ptr.

...

Here is an example of what this could display:

example_io.cpp(83): Throw in function class boost::shared_ptr<struct _iobuf> __cdecl my_fopen(const char *,const char *) Dynamic exception type: class boost::exception_detail::clone_impl<class fopen_error> std::exception::what: example_io error [struct errno_ *] = 2, OS says "No such file or directory" [struct file_name_ *] = tmp1.txt [struct function_ *] = fopen [struct open_mode_ *] = rb

1. This is not very readable at best?

I'd agree that it isn't user-friendly; to a programmer it should speak volumes. :)

...

The string is pretty much guaranteed to be ugly to look at yet rather informative. :)

I believe you gave up too early. You should not take over formatting of the error messages (you can provide default I guess)

This is *not* an error message, it is an automatically-generated diagnostic message for exceptions that should have been handled (to generate a proper user message) but weren't. It is about as pretty as a core dump, and about as useful.

2. What if I want to generate XML log instead?

You'd just have to filter the returned string for < and >, etc.

3. What if I do not want to display anything at all, but store in some file?

It's a string, you can do with it whatever you want.

After some testing it seems that BOOST_THROW_EXCEPTION only works with types inherited from std::exception.

This requirement comes from boost::throw_exception, to support -fno_exceptions builds, where the user is required to define a non-template std::exception overload for boost::throw_exception. BOOST_THROW_EXCEPTION calls boost::throw_exception and hence has the same requirements. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

On Mon, Aug 10, 2009 at 9:45 PM, Robert Ramey wrote:

Emil Dotchevski wrote:

...

On Mon, Aug 10, 2009 at 5:37 PM, Gennadiy Rozental wrote:

...

Does this require some kind of RTTI?

Some kind, yes, to provide type safety. If the built-in RTTI is disabled, Boost Exception uses the same workaround used by shared_ptr.

I'm curious as to what the statement above refers to. I don't remember anything in the shared_ptr documentation which refers to that.

It isn't a documented feature, it's only used internally by both libraries. See boost/detail/sp_typeinfo.hpp, and boost/exception/detail/type_info.hpp. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

Gennadiy Rozental wrote:

Alexander Lamaison writes:

...

Are there any plans to let the Boost.Test runner make use of the extra information that the Boost.Exception library is able to 'inject' into exceptions?

Looks reasonable. Let's see if I can put use this info.

I'll let you know once this implemented.

Support is implemented in revision 55515. Please Let me know if you see any issues. Gennadiy

On Wed, 12 Aug 2009 00:17:44 +0100, Alexander Lamaison wrote:

"Gennadiy Rozental" wrote in message news:4A80BDBD.1000005@gmail.com...

...

Support is implemented in revision 55515.

I'll try and test it asap. I've never built any boost libraries myself so there may be a bit to learn here.

Seems to work perfectly for me. The failure messages are a little more verbose that I anticipated but what exactly did I expect when using templates? :P c:\users\awl03\documents\visual studio 2005\projects\swish_feature_write\test\shell_folder\shell_data_object_test.cpp(145): fatal error in "class comet::com_ptr<struct IDataObject> __cdecl `anonymous-namespace'::ui_object_of_items >>(class std::_Vector_iterator >,class std::_Vector_iterator >)": std::exception: The parameter is incorrect. Thanks for all your work! Alex