What do you do if your error logging fails, and how do you test that its working in production?

Question

1. What do you do if you're error logging code fails?
2. How do you make sure that its currently working?
3. How do you know if its not working?
4. How do you test that its working in a production environment?
5. Should I throw an exception if all else fails?

The code below uses Microsoft's Enterprise Library Logging Application Block. How do you make it "better"?

using Microsoft.Practices.EnterpriseLibrary.Logging;

class Program
{
    static void Main(string[] args)
    {
        try
        {
            // Trying to write some data to the DB
            ...
        }
        catch (Exception ex)
        {
            LogHelper.LogException(ex, "Trying to write to the DB");
        }
    }
}

public class LogHelper
{
    public static void LogException(Exception ex, string exceptionType)
    {
        try
        {
            // Simplified version, only logging the message
            Logger.Write(exceptionType);
        }
        catch
        {
            // What do you do here???
        }
    }
}

Answer 1

My apps usually do two things on an error. The first is to write it to a local log file (even if it uses some type of database logging as well). Then it sends an e-mail of the error to a distribution list set up for support.

So if the database log write fails, the error is still in the local log file and also sent via e-mail.

If the e-mail fails, the error is still logged so you can troubleshoot the problem later.

Getting more fault tolerant than that would only be worth the effort for extremely mission critical applications, IMHO.

Ron

Answer 2

See the answers in my related question:

If everything else fails, have a 'last resort logging' in your catch block. Log the exception to a text file in a location where this is highly unlikely to fail. If this last resort logging fails by throwing another exception, you can either swallow that exception, or terminate your app and display the error as a message box.

In this specific (exceptional) case, swallowing the exception is the only way to not terminate the app.

Answer 3

I write a log file as well as have an email sent to a common address that will never go away. Neither are bullet proof but I would think that if our mail system is down or the email server changes we would know about it. I do have some apps that write to both a database and a flat file and send the email. So one of the 3 is going to work. I found one of my apps was writing to a db for the log and in the catch it was writing to the same db and the only way I found it was the app was failing because of some changes in the db connection. I made sure to modify that catch statement do the email instead of the db. The only problem I have with flat files is file system storage, we have a lot of applications that write flat files for logs so we are constantly backing them up and saving them or just plain deleting them.

Answer 4

check out this question