Mark Blewett wrote:
At 19:03 29/04/2005, you wrote:
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)?
First of all, it should be clear that the above is just a sketch. The code we have is a bit more complicated and I might even describe some features that are possible but not yet implemented in our companies code base. But to answer your question: Basically logger.print() protects itself, inside its implementation. If the logging itself fails (not the evaluation of the expression to log), the log system handles the situation on its own. As an example, if the log-target is a file and the disk is full, it just stops logging, probably trying to inform someone via EMail or whatever other options are available, depending on the context.
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.
If the application is meant to run 24/7, how do you react on a "disk-full" error? In the end, it's just the log-system. By definition (YMMV), the application should be feature complete even without any log-messages. I know that some people put important information in log-messages that are part of the applications functionality, but to me this always seemed like a bad idea. Thus, in case anything fails during logging, we try to handle the situation as gently as possible to keep the application running. Regards, Daniel