As software developers we make dozens of design decisions daily, some are more subtle than others.  Recently, I briefly reconsidered returning error values instead of exceptions to signal error conditions.

As a general rule my policy is to throw exceptions except when I’m the only consumer of the method and if I am the only consumer of the method it is sometimes OK to return a BOOLEAN value to signal success or failure.

The obvious reason to avoid exceptions is that they are invisible in the source code, especially in C#.  Looking at a block of code there’s no way to see which exceptions will be thrown and from where. Exceptions also create too many exit points from your function, and as a programmer you must be aware of all of them.  Finally, your program takes a small performance hit when you use exceptions because exceptions throw off the stack frame.

I’m still inclined to continue using exceptions.  Anyone who has worked on applications with several developers knows how difficult it is to maintain functions that return error values– as the program grows developers add new return values and it’s not easy to determine which error value corresponds to which error condition.  Using return values to indicate errors leads to software that is more difficult to maintain.

Exceptions also force the caller of your method to deal with the exception, it is very easy to ignore return values, and an unhandled exception will stop your program from executing.  Additionally exceptions let the developer choose where the error should be handled.  Code can be written to catch exceptions near the failure point, or further up the stack.  With return values your error handling code must be near the point of error; often the mechanism to deal with the error (i.e.: the user) is not available at the point of failure.

This being said, I’m not advocating throwing generic exceptions, you as developer must consider how your code will be used and throw exceptions which properly convey the type of errors your method may encounter.

Using exceptions instead of returning error values allows your program to be more flexible and easier to maintain, I can’t think of any good reasons to stop using exceptions.  What are you opinions?

Tom’s talking ’bout his role at his job and I’m still not sure if I really know what he does at work, but his post reminds me of the “5 things you didn’t know about me” meme which was so popular several months ago; in honor of that meme, and because bloggers love talking about themselves I’m tagging Ben and James with the “What do You Do?” meme.

Let me start:

I’m a senior software engineer at a small software development company in Karachi. Most of my work revolves around integrating third party applications, i.e.: Project Server 2007, with Microsoft Dynamics Navision 4.0 (an ERP) and customizing different modules and reports in Nav. I also spend part of my time working on ASP.NET applications and writing Perl scripts to automate Navision migrations.

I use the same development tools that you use, Visual Studio 2005 and jEdit for my editors/IDE, SVN for source control, MbUnit for Unit testing, WATIR for web application testing. The only uncommon tool you’ll find on my computer is Beyond Compare—THE single best file and directory comparison utility I’ve ever used.

So, what do you do?

I’m a big fan of Unit Testing, even more now that I’ve upgraded to MbUnit, it’s certainly much easier to test the data access layer with MbUnit, but I’ve found it nearly impossible to unit test my Project Server interfaces, I don’t know how to undo an insert/update in Project Server, has anyone figured out how to rollback transactions on Project Server using a Unit testing framework?