Following on from my article on good source control check-in habits, I've got a few tips I'd like to share on exceptions in .NET. These are basically all responses to things I've seen done in production code before.
Write a method that throws -- don't return success/failure codes
Here's a C function I wrote a couple of years ago for an application a couple of years back that listens for messages via UDP:
C has no formal mechanism for functions to return to their caller when exceptional behaviour is encountered. Instead they typically return an integer status code (e.g. 1 or 0) to indicate success or failure.
Clients using these functions must check for errors after every call. Because of this:
- Your real application code can be much harder to follow when it's hidden amongst all the error handling code (which probably only executes in rare circumstances anyway).
- If you accidentally omit a return code check and something fails, your program will continue happily executing as if nothing happened. Problems might not become apparent until several operations later, making it much harder to track down the original issue.
- Because you have to check for errors the whole way (and at different levels), there will be a lot of duplicated code, violating the DRY principle.
- Error codes can overlap with legitimate return values, making it hard to indicate when an actual error has occurred. This is known as the semipredicate problem.
- Sometimes things happen that are so catastrophic, you don't even bother with a strategy for trying to cope with them. For example, it might be perfectly acceptable to die if malloc() fails, unless you're fully equipped to keep your program running when the machine is out of memory.
Languages like .NET are free from these worries because they use a different strategy: assume everything will always succeed (try), and handle any problems later in one single location (catch).
This lets you focus on the success case (the one that actually matters), instead of cluttering your code up with error handling.
Unfortunately, it seems a lot of .NET developers only think of exceptions as things you need to catch when calling the Base Class Library, and shy away from throwing and catching their own exceptions. Instead, I see kludges like: Or even this one, which simulates Exception.Message:
The golden rule is, if your method encounters a condition that prevents it from achieving its intended purpose, it should throw an exception.
Do you know the difference between the two following code snippets?
The first example resets ex's stack trace to the current location. This is fine when you're throwing a brand new exception, but not so good if you're just passing one along -- you'll lose the stack trace telling you where it originated from.
To preserve the stack trace, just use "throw" by itself with no argument, as in the second example.
Use parameterless catch/throw if you don't care about the details
You don't have to specify any parameter name in your catch block if you don't need the exception object itself:
This is handy for eliminating that "variable 'ex' is not used" compiler warning. In fact, if you don't care about the type, you can get rid of the brackets altogether:
But be careful with one -- in 99% of situations, we do care what the type is.
Only catch exceptions you can handle
Imagine you are working on some code that tries to parse some user input as an integer. If it's invalid (e.g. not a number), we'll display an error message.
What's wrong with this? We've specified that this catch block is capable of handling any type of exception, no matter how severe or unrelated. They'll all be interpreted as validation errors -- OutOfMemoryException, ThreadAbortException -- even NullReferenceException (which might indicate an actual bug in the code).
In reality, however, all we really care about is a very narrow subset of exceptions: those that indicate the number couldn't be parsed correctly.
Only catch exceptions you anticipate could be thrown as a consequence of the code within your try block. Don't try to handle anything outside that window, unless you have a specific strategy to deal with it.
Multiple catch blocks
Here's an example of some code I saw at my last job, that did different things depending on the type of exception:
Yuck -- using reflection and a big if-statement to differentiate types is generally a sign of bad code in .NET (or any OO language), and catch blocks are no exception (ba-dum-psh). Instead, use multiple catch blocks with overloads for different exception types. At runtime, the .NET framework will call the first matching catch block, so you need to specify them in most-to-least specific order:
In .NET, low-level exceptions can be wrapped up into a higher-level context that makes more sense in the grand scheme of things. For example, a CouldNotOpenDocumentException might be caused by a FileNotFoundException. This is reflected in the Exception.InnerException property, and inner exception each is complete with its own error message and stack trace.
Here's some code I saw once for unwrapping them, via a loop:
This code is pretty redundant (and ugly), as the .NET framework will do this for you. Exception.ToString() will print out the exception's message and stack trace, then call itself on the inner exception:
This will return a complete dump of the inner exception tree, producing a message like:
Another tip for is finding the root inner exception -- the original cause. The developers from the previous example chose to drill through InnerExceptions in a loop until they reached the bottom (null). An easier way would just be to call Exception.GetBaseException().
To write robust and idiot-proof code, you have to assume people are going to try to break it. This means checking input parameters are valid at the start of every method.
You should continue this habit all throughout internal application methods as well, so bad data gets stopped short at the point of origin, instead of trickling through and causing problems later on.
Note that Microsoft's Spec# contracts will make these sorts of checks much easier in future, with built-in syntax for not-nullable parameters:
Plus these rules are enforced at compile time as well! So the following line would not build:
ProjectsController controller = new ProjectsController(null); // error
See Microsoft's article on Best Practices for Handling Exceptions for more .NET exception tips.