I’ve seen from time to time applications that wrap a TRY – CATCH around some code, but do nothing except carry on.  So why is this so wrong?

As programmers we want to write quality code that solves problems. Unfortunately, exceptions come as side effects of our code. No one likes side effects, so we soon find our own ways to get around them. I have seen some smart programmers deal with exceptions the following way:

public void consumeAndForgetAllExceptions(){
    try {
        ...some code that throws exceptions
    } catch (Exception ex){
        ex.printStacktrace();
    }
}

What is wrong with the code above?

Once an exception is thrown, normal program execution is suspended and control is transferred to the catch block. The catch block catches the exception and just suppresses it. Execution of the program continues after the catch block, as if nothing had happened.

How about the following?

public void someMethod() 
 {
 throw new Exception();
 }

This method is a blank one; it does not have any code in it. How can a blank method throw exceptions? C# does not stop you from doing this. Recently, I came across similar code where the method was declared to throw exceptions, but there was no code that actually generated that exception. When I asked the programmer, he replied “I know, it is corrupting the API, but I am used to doing it and it works.”

This debate goes around in circles in the C# community. I have seen several C# programmers struggle with the use of exceptions. If not used correctly, exceptions can slow down your program, as it takes memory and CPU power to create, throw, and catch exceptions. If overused, they make the code difficult to read and frustrating for the programmers using the API. We all know frustrations lead to hacks and code smells. The client code may circumvent the issue by just ignoring exceptions or throwing them.

Let’s go back to basics and start with the definition of an Exception:

Exception handling is the process of responding to the occurrence, during computation, of exceptions – anomalous or exceptional conditions requiring special processing – often changing the normal flow of program execution. It is provided by specialized programming language constructs or computer hardware mechanisms.

The important words here I feel is special processing something which is out of your control.

Here is a simple example

 var a = 0;
 int b;
 try
 {
  b = 10 / a;
 }
 catch
 {
 }

So what is wrong with this?

I call it lazy and poormans programming, one correct solution to this could be:

 var a = 0;
 int b;
 if (a != 0)
  b = 10 / a;

Okay this is a very simple example of abusive Exception handling, but does it really matter?

I wrote a small benchmark test to see just what the difference is in performance.  Just a simple 10,000 parallel loop count running the same code over and over again.

I was quite overwhelmed with the performnce hit of the Exception handling, even just in this small example.  The Exception handling caused the code to slow down by over 600 times.

600 times slower code, well that does not matter if this is only happening once I hear you say…!

The performance is just one area, what about the extra memory that the exception is using.  With a few changes to the Benchmark application am able to monitor the Garbage Collector, which although it is not a true representation of how much memory is being used it will provide a very good gauge.

The results of the memory useage were quite staggering

• 14,416 for the programming logic
• 2,501,832 for the exception handing

Just another reason why this is not acceptable to use the exception handler in this way.

This is just a short article on Excpetion Handling, but it does frustrate me when I see Exception Handling  being abused.

ExceptionPerformance