Exception Handling The Right Way

Methodology Add comments

Exception Handling the right way

If you are just joining us, this is part 2 of a series on programming foundations and good practices.

Part 1 - Object Oriented Programming Is Your Foundation

Exception handling can be an extremely powerful tool for debugging…if it is done right. If you drop the ball on this it can make you want to run home crying to your Mommy. I’d like to point out that I thought it was a bit ironic that I stumbled onto this post from Daily Coder on Exception Handling today. I didn’t copy them. Honest!

When a user encounters an error

It is usually enevitable that your applications will have bugs. It is just a fact of life. No matter how diligent you are you just can’t predict eveything a user might do to break your code and things like unit testing just don’t catch everything.

So when a user encounters a bug in your application what should they expect? Well, idealy they will receive a nice friendly message explaining that something went wrong. No technical mumbo jumbo. The user doesn’t care. They just want it to work. Your error messages should give suggestions on what to do or how to report the bug to the proper people.

I have encountered far too often horrible error pages that are just a dump of the stack trace. Gross! Are you trying to scare your users away? This just makes the problem feel worse to the user. YSOD anyone?

Have an error tracking system in place

It doesn’t matter what you use but you should have some sort of system in place to track errors. This way when the application encounters an exception it can log it to your system and you are notified that there was a problem long before the user even reports it.

These systems are invaluable. You cannot rely on the customer to provide the proper details about the error. It is not their job. It is yours. I get emails and phone calls often from clients saying that such and such is broken or the system is broken. Not exactly helpful.

Because of reports like that I learned early on to log errors with as much detail as possible. I also like to include a user activity log that tracks where and what the user is doing in the system. This provides me with information on what the user was doing leading up to the error and makes diagnosing the problem that much easier. An activity log also lets you see patterns in the way users use your application and can reveal possible problems you didn’t previously anticipate.

Throwing an exception the wrong way

Here is the wrong way to throw an exception.

protected void Page_Load(object sender, EventArgs e) {
	MethodOne();
}

void MethodOne() {
	try {
		MethodTwo();
	}
	catch(Exception ex) {
		throw ex;
	}
}

void MethodTwo() {
	string[] arr = { "one", "two", "three" };
	Response.Write(arr[5]);
}

The output we get is

Index was outside the bounds of the array.

Line 23: }
Line 24: catch(Exception ex) {
Line 25: throw ex;
Line 26: }
Line 27: }

The line that rethrows the exception is marked as the line that is at fault which is not true and doesn’t help us much in figuring out what is causing the problem.

Throwing an exception the right way

Now that we know what not to do, here is the proper way to throw an exception.

protected void Page_Load(object sender, EventArgs e) {
	MethodOne();
}

void MethodOne() {
	try {
		MethodTwo();
	}
	catch {
		throw;
	}
}

void MethodTwo() {
	string[] arr = { "one", "two", "three" };
	Response.Write(arr[5]);
}

Notice that I am not using ‘throw ex’, I am only using ‘throw’. This masks the fact that we intercepted the exception and throws it as though we had not. Now our output is:

Index was outside the bounds of the array.

Line 29: void MethodTwo() {
Line 30: string[] arr = { “one”, “two”, “three” };
Line 31: Response.Write(arr[5]);
Line 32: }
Line 33: }

This is what we wanted. It shows us the correct line that is causing the problem.

Putting it all in perspective

By now I hope you see the importance of proper exception handling and logging. It makes it easier to track down bugs in your programs by giving you details that the user can’t or won’t be able to give you. Also making sure you throw the errors in the right way will give you even more specific details as to where the problem is occuring.

kick it on DotNetKicks.com

Popularity: 8% [?]

If you liked this article consider subscribing to my free rss article feed to automatically get new articles in your feed reader.

Leave a Reply

WP Theme & Icons by N.Design Studio
Entries RSS Login