I get really uptight when I see the way some people use, or should I say misuse, error handling in VB/VBA projects; There is an On Error Resume Next statement at the top of a procedure and nothing else – I always read such a line as  meaning that there is an error in here somewhere but the author was either too lazy to do anything about it or did not understand the issue. Such a statement effectively means that you ignore any error that occurs and carry on executing code line by line, which may; a. be a waste of time because of the error and produce further error conditions or, b. cause the calling routine to blindly continue executing with erroneous results.

 

Along came .Net and Exception Handling (acknowledging that it was around long before in some languages) and I thought just maybe the different paradigm would help – unfortunately not and we now see code, sometimes a whole procedure, wrapped in a Try – Catch block that looks like this in C#:

 

try

{

//Do work here

}

 

catch (Exception e)

{

//Handle error here

}

 

This is slightly better than the old way because at least the code after an error will not be executed but still demonstrates a lack of understanding, unless the developer really did intend to deal with any and every possible error condition such as a hard disk failure or an out of memory condition. System.Exception is the base exception class from which all exceptions are derived and should never, IMHO, be used.

 

Others, more knowledgeable than myself, have written articles on Exception handling (here, here and here) but my view of the world is; Don’t use it!

 

OK – now I had better explain myself before I get flamed for making such a brash statement; what I really mean is ‘Don’t use Exception Handling during development until you understand the issues’.

 

We need to understand the word ‘Exception’ should be taken to mean an exception to the normal sequence of events which, to my mind, implies that we need to understand fully what is ‘normal’ before we can deal with what is ‘exceptional’

 

The consequence of that understanding is to examine the difference between what is to be expected and what is truly exceptional. Take a look at the following:

 

public decimal Divide(int number, int divisor)

{

return number / divisor;

}

 

A simple function which divides one integer by another and returns a decimal result – fairly straight forward but anyone who has been around programming for more than a few weeks knows that computers do not understand the concept of dividing by zero; so we need to handle the problem.

 

public decimal Divide(int number, int divisor)

{

decimal result = 0;

try

{

result = number / divisor;

}

catch(Exception e)

{

//deal with the problem depending on requirements and context

}

return result;

}

 

Remembering that I said earlier we should not use System.Exception and it happens that divide by zero is so well known that the .Net Framework team provided a specific exception for it – so our example looks like this;

 

public decimal Divide(int number, int divisor)

{

decimal result = 0;

try

{

result = number / divisor;

}

catch(DivideByZeroException e)

{

//deal with the problem depending on requirements and context

}

return result;

}

We are no longer handling any and every thing that can go wrong; instead we are handling the specific problem. But is this known issue really exceptional?

My answer would be a resounding no! It is such a common error that it should be expected and not thought of as exceptional.

That realisation then allows us to deal with it differently:

 

public decimal Divide(int number, int divisor)

{

if(divisor == 0) divisor = 1;

return number / divisor;

}

 

There are a couple of benefits of changing our function like this;

 

Firstly we have less code; in fact we are back to the original function with one extra line, although this may not always be the case.

 

Secondly we have prevented the possibility of a divide by zero condition occurring which must be a good thing: OK don’t take my word for it let’s reason it through:-

1. It makes our code more robust because we prevent an error.
2. By putting an exception handler around a set of statements we are telling the system to try and see if something works and if not do something else. My intuition is that the system needs to, at the very least, store the state prior to entering the Try block so it can re-establish it if something goes wrong and it has to execute the Catch block. If that is the case then, as well as adding complexity to your code, there must be a performance hit. (Here is a good article on Exception Handling where Performance is mentioned– Updated with Link)

 

My own practice is to not include any exception handling until after I have finished coding and testing – that way I find, hopefully, all the ways that my code can go wrong and put in code to deal with it on the basis that if I find an issue during my coding and testing then, by definition, it cannot be an exception.

 

Now despite all of our efforts we have to acknowledge that true exceptions (i.e. someone pulls out a network cable) will happen so we then need to make some decisions about how and where to handle them, which I will talk about at another time.