At 19:03 29/04/2005, you wrote:
John Torjo wrote:
I've just updated the Boost Log Library: http://torjo.com/code/logging-v132.zip
It's good to see progress on logging and what I've seen so far looks promising. However...
BOOST_LOG(app) << "testing " << i << '-' << j << '-' << k << std::endl; BOOST_LOG(dbg) << "this is a debug message, i=" << i << std::endl; BOOST_LOG(info) << "I just wanted to tell you something....";
...while I like the feeling of the stream approach from a user's perspective,
I agree.
there is one (IMHO important) feature that can not be implemented with it: Exception guards.
To illustrate my point, consider a "pure MACRO approach" like this:
std::string f() { throw 42; }
BOOST_LOG( app, "Huhu!" + f() );
where BOOST_LOG is:
#define BOOST_LOG( logger, message ) \ do { if( logger.is_enabled() ) { \ try { logger.print( message ); } \ catch( const std::exception& e ) { \ logger.print( "Can't log \"" #message "\", e.what(): \"" + \ std::string( e.what() ) + "\"" ); \ } \ catch( ... ) { \ logger.print( "Can't log \"" #message "\", unknown exception" ); \ } \ } } while( false )
What happens if logger.print() throws (say because there isn't enough disk space to write a log to)? I've always taken the other view (being a developer for server applications that have to run 24/7) that if you can't write to the log, you don't jeopardise the application.
This feature helped us several times in the company when a log-message, calling some complicated functions, failed in a production system. As long as the above technique is applied, the log-file contains a good hint for us what's wrong and the product is still running without the customer noticing.
Regards, Daniel
Regards Mark