Skip Navigation LinksHome > View Post


The subject of Exceptions vs. Return Codes appears frequently in the newsgroups, and I feel pretty passionate about this so I want to discuss my feelings in more detail here.

First, lets make it clear exactly what it is we're arguing about. On one side of the fence, we have developers who like to throw exceptions when something isn't as should be. On the other side we have those who prefer to return a flag that indicates something wasn't quite right. A good example is the old MSXML DomDocument from my now (thankfully) distant VB6 days versus the new System.Xml.XmlDocument (from .NET).

Both are object representations of XML documents and work in similar ways. They both have a Load method which takes a string parameter where you can specify the path of an XML file. But there is one crucial difference herein.

The .NET version's Load method is void (doesn't return anything) whereas MSXML's Load method returns a boolean to indicate the success of the operation. If you've not guessed already, I'm a big fan of the former and strongly opposed to the old MSXML way.

ATM displaying the classic 'Object or with block variable not set' error message

What's the big problem?

Well, I think there are a number of issues with the latter approach. But lets demonstrate just one of them by considering what happens when something does go wrong. Let's imagine the file specified in the path does not exist.

In .NET, the XmlDocument throws an Exception:

System.IO.FileNotFoundException: Could not find file 'c:\example.xml'.

In the old COM world all that would have happened is that the Load method would have returned false. If the developer forgot to check this flag, the next thing we'll see is the VB6 equivalent of a NullReferenceException. Now that's not very helpful is it?

I can hear some of you at the back shouting "But I always checked the return value of the Load method", to which I ask: "And what did you do if it was false? Raise a FileNotFoundError??". This is besides the point, because everybody forgot to check the return value and went through that pain. What we have now is better.

So what is an exception?

The most common answer is "an exceptional event" but this is a subjective view. Do you think a missing file is exceptional? My point is, what's unexceptional to you may be exceptional to someone else.

I think Jeffrey Richter nails it in his book Applied Microsoft .NET Framework Programming:

"An exception is the violation of a programmatic interface's implicit assumptions.".
You can't load an XML file that doesn't exist, so throw an exception!

Are there any, ahem, exceptions?

There are grey areas where you have to choose what works best in that particular case. For example, in the .NET BCL (Base Class Library) the Dictionary<> class will throw a KeyNotFoundException if you pass a key that doesn't exist in the dictionary, whereas the Http Cache just returns null if a key doesn't exist.

If your API implies it's going to perform a 'search', where the possibility of no results is clearly implied, it might be most appropriate to return an empty list or if only a single result is expected - null maybe appropriate in this case.

Tags: .NET

Josh Post By Josh Twist
11:46 AM
19 Apr 2006

» Next Post: Premature Optimisation
« Previous Post: Validator Source available for download

Comments are closed for this post.

Posted by Munawar (software Engineer) @ 23 Apr 2006 11:13 PM
I can say.... this is some cool stuff to work arround... the guy has spended worthy time to put here the best approach ... for optimization the code and paths..

© 2005 - 2014 Josh Twist - All Rights Reserved.