When an error occurs in your application, it creates an “exception” – a disruption to the normal course of execution of the program. Most modern languages support a way to handle these exceptions – in .NET, there are three portions of an exception handling block – the try block, the catch block, and the finally block. It is only required that you use either the catch or the finally block – you are not required to use both.
So we would like to share with you some of the exception handling pitfalls we have seen:
- Make sure that if the code in your catch or finally block can fail, you have that code itself in a try … catch block. For instance, Microsoft’s own C# sample on the try-catch-finally page in MSDN makes me cringe a bit. If there were somehow (perish the thought) the potential that the StreamReader .Close() method could throw an exception, then this exception handling block would not work.
- Should you be using a “using” statement instead of “finally”? In the aforementioned MSDN example, StreamReader implements IDisposable. So it makes for tighter code to use “using” instead of a finally block. With “using”, there is no chance that you can accidentally refer to the destroyed object later in your code.
- When an exception is thrown, it will get caught by the exception handler closest to the exception – regardless of how far away it is. For instance, suppose you are function that processes financial transactions. During transaction #43, you need to prompt the user for additional information. An exception is thrown reading the file the user provides. If you trap the exception in this interior function, then you can prompt the user for another file. If you don’t, then it’s going to go all the way up the stack until it finds a try block.
- Update your legacy VB exception handling code. In VB6, you had two options for error handling, both of which are maintained in VB.NET for backwards compatibility – On Error Resume Next, which means that when an error occurs, the application simply moves on to the next statement – and On Error GoTo labelname, which sends the error to a predefined location in code. Both of these legacy methods of handling exceptions get translated into monstrous try … catch blocks when your application is compiled.
- Generally, place your exception handling inside of a loop, not outside of it. If you place the try … catch block outside of a loop, then you have potentially lost the looping variable, making it more difficult to report to the user a meaningful error. You also lose the option of resuming your operation.
- The specific exception types are there for a reason – use them. If you conducting a file operation, trap FileIOException. If you are conducting a web request, trap WebException. Don’t just use Exception for everything. Sometimes, the exceptions have meaningful information and don’t necessarily mean “error”. For example, with some web servers, a redirect throws a WebException and the new URL is given at WebException.Response.ResponseUri.
Want to talk to our eBusiness team about programming tips or how we can more efficiently handle your application build? Contact us here at our tech home on the web.
image credit: Peter Suneson