In my last post we set up a minimalist application, attached Gibraltar to it, and reported some trace information. In this post we’re going to build on that and add exceptions. First we are going to add an unhandled exception, so we change our code so that it looks like this:

using System.Collections.Generic;
using System.Linq;
using System.Diagnostics;

namespace GibraltarGettingStartedApp
{

	class Program
	{
		static int Main(string[] args)
			{
				Trace.WriteLine("About to Blow up...");
				int zero = 0;
				Trace.Close();
				return 1 / zero;
			}
		}
	}
}

That should get the runtime’s panties in a bunch, let’s try it.

Yep, that did it! Now, let’s see what Gibraltar logged…

Gibraltar knows we crashed and if we open up the record…

We know what the problem was, we can click the link and go right to the line in the source code and Gibraltar tells us what the user experience is going to be, “This fatal error will not be reported to the user, then the application will exit”. All and all, pretty cool.

As an aside, let me close down VS, I want to test if I click the link, will it open the file and go to the line? It does! That’s cool, though I notice that it only opens the actual file and not the solution or project that the file is in. Hmm, I’ll need to investigate that more as it’d be better if the entire solution was opened, don’t you think?

Let’s try running the same unhandled exception in a winforms application and see what happens. We’ll need to run the exe from the commandline, as the VS debugger will “get in the way” and try to do “clever stuff”, but when we do, we see the following dialog:

Here Gibraltar is giving us even more help. It’s popped up a dialog which will actually help us recover from the crash and carry on using our application. If we select “Restart Application” Gibraltar will restart the application for us and enable us to carry on using our application. Of course, this facility should only be used in a testing environment. In the real world, I don’t think it would be wise to restart and to continue using an application which had just suffered from a crash, as there is no way to know what state the underlying model is in. However, from a testing perspective, it’s an excellent tool.

Of course, the same information is recorded in Gibraltar:

Notice that the “Status” has been recorded as “Normal”. If we open the record we can see why:

It’s because we chose to continue the execution and shut down the application normally after.

Okay, let’s change our console application code to handle the exception…

using System;
using System.Collections.Generic;
using System.Linq;
using System.Diagnostics;

namespace GibraltarGettingStartedApp
{
	class Program
	{
		static int Main(string[] args)
		{
			Trace.WriteLine("About to Blow up...");
			int zero = 0;
			Trace.Close();
			try { return 1 / zero; }
			catch (DivideByZeroException e) { }
			return 0;
		}
	}
}

And let’s see what difference that made to Gibraltar…

Hmm, as far as Gibraltar is concerned everything is normal, there is no sign of the handled exception. For a clue as to why that is, let’s examine logging best practices, you can read them at…

http://www.gibraltarsoftware.com/Support/Documentation/Logging_BestPractices.html

And they quite clearly state:

“We strongly recommend that in all cases where an exception is consumed within a catch block that you log the exception with an Informational severity rather than silently swallowing the error.”

Okay, so this states that if we handle an exception, and we want that fact recorded by Gibraltar, then we have to log it. That makes sense really. So, let’s change our code to the following:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Diagnostics;

namespace GibraltarGettingStartedApp
{
	class Program
	{
		static int Main(string[] args)
		{
			Trace.WriteLine("About to Blow up...");
			int zero = 0;
			try { return 1 / zero; }
			catch (DivideByZeroException e)
			{
				Trace.WriteLine("Error: " + e.Message);
			}
			Trace.Close();
			return 0;
		}
	}
}

Now let’s see how that’s affected Gibraltar:

This time you can plainly see that the error has been recorded, which is good, but notice too that there’s no exception tab:

Of course, we should be able to do better and we can. If we use the TraceInformation method, and pass a formatted string, along with the exception, then Gibraltar will give us a much richer experience.

So, let’s change our code to use that method:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Diagnostics;

namespace GibraltarGettingStartedApp
{
	class Program
	{
		static int Main(string[] args)
		{
			Trace.WriteLine("About to Blow up...");
			int zero = 0;
			try { return 1 / zero; }
			catch (DivideByZeroException e)
			{
				Trace.TraceInformation("Error: {0}",e.Message,e);
			}
			Trace.Close();
			return 0;
		}
	}
}

And let’s look at the information provided in Gibraltar:

This time, as you can see, we get the “Exceptions” tab. This is because Gibraltar scans the insertion variables and, if it finds one that is an exception, then it uses that as the exception for the log message (regardless of its severity). Pretty cool eh?

In this post we added an unhandled exception to your console application to see what effect that had on Gibraltar. We then added an unhandled exception to a winforms application so we could see the enhanced features available to us there and then we finished up by handling that exception and seeing why best practice is to log handled exceptions.

I hope you’ll join me next time as we continue our exploration of Gibraltar, until then, happy coding!

try
{
m_Parameter.Value = m_Parameter.ConvertValue(txtParameterValue.Text);
}
catch(Exception ex)
{
//even though we expect exceptions,log it in case it isn't why we expect.
Log.TraceInformation(ex, "User provided invalid parameter value/r/n" +
"Unable to convert to native type.  The new value will be ignored.");
}