Logger Exception Not Thrown

Topics: Logging Application Block
Jul 20, 2007 at 9:37 PM
Edited Jul 20, 2007 at 10:17 PM
I have ran a simple test for logging and exceptions. The test should have thrown an exception since the SQL Server service was stopped on the database trace listener. Instead the Visual Studio Team Suit unit test (similar to NUnit test) passed. I expected to see an exception and the test fail.

I went into the QuickStart for logging and looked at the Logger class. An exception event gets to routed to the ReportExceptionDuringTracing method which appears to recatch the exception and route the failure to the method: instrumentationProvider.FireFailureLoggingErrorEvent. I don't have instrumentation implemented.

Has anyone went through this and is instrumentation required to handle logging failures due to the trace listener sink not being available. If no answer I will investigate further.


btw - this test did pass and the log was created in the database when the service was on.

here is the test code:

public void LoggerTest()
LogEntry log = new LogEntry();
log.Message = "Your message here…";
log.Priority = 1;
log.EventId = 100;
//TODO (bjm) - this test passed even though the associated sql server instance was stopped.
//need to determine why.
Jul 21, 2007 at 3:56 PM

This is actually by design, The block will not raise exceptions so the application doesn't have to deal with them.

Jul 23, 2007 at 2:38 PM
This should generate an exception from SQL Server since the code tries to access the database and the server service is stopped.

I found that the library is logging the exception to a log file. But, I can't stop the logging to let the exception go up the stack and be an unhandled exception. I've turned all logging off as much as I can.

Jul 23, 2007 at 2:54 PM

Like I mentioned before, the Logging Block will not let exceptions bubble up to the application and instead it will attempt to log them. If you want to change this behavior you'll need to modify the source code, but this is not recommended.

Why do you need to handle the exception in the logger? Keep in mind that the logging block is configuration driven, so you can have a sql trace listener just like you can have an event log trace listener, and your application's code should not depend on this. If your application needs to write to a database and needs to make sure it succeeded, you might be better off not using the logging block.

Oct 24, 2007 at 3:30 PM
I am in a broadly similar situation. For the majority of messages, if there is an exception writting to the sink, thats fine.

However, for certain auditing messages, I need to guarantee delivery to at least one sink. The flip side of this being if the message was NOT delivered, then the app needs to know about it and stop as this could be an attempt to subvert the audit logging.
Oct 25, 2007 at 5:04 AM

Like I mentioned above, if you have a specific requirement for guaranteeing the delivery of a message then you should not use the logging block.

I'm curious. In your scenario, is the ability to configure different destinations for the logged entries valuable? I mean, is it that it doesn't matter where they get logged as long as they get logged?

Oct 25, 2007 at 9:52 AM
I'm curious. In your scenario, is the ability to configure different destinations for the logged entries valuable?

I need to clarifty this with the business to see if it really does matter. For example, If we write audit to both DB and flat file, we would not expect both to fail, so is it enough that we have at least one record of the audit event?

I think that the ability to know whether or not a message generated an error within the logging framework would be a valuable addition.