Software errors, are so prevalent and so harmful that they cost the U.S. economy an estimated $59.5 billion annually. There are many examples of very serious and detrimental software errors such as:

softwareErrors Obviously, we would like to deliver a “bug free product” to our customers, but unfortunately, this is an un achievable goal. While some errors can be very easily eliminated, other are very evasive. What are the measures taken into consideration when we decide if an error is evasive or not? Lets create a list of software error parade and talk about it:

1. Data or memory corruption

From Wikipedia: “Memory corruption happens when the contents of a memory location are unintentionally modified due to programming errors. When the corrupted memory contents are used later in the computer program, it leads either to program crash or to strange and bizarre program behavior”.

Notice to the phrase: “used later in the program”, this is the why I think that those are the most difficult errors. Your program doesn’t crash when the bug happens, it will crash later on at any point and inconsistently. Those kinds of errors are very hard for debugging and even worse they might not “reveal” during the development process but in the field when the customer already have the product. Another reason why I decided that this kind of errors will march in the top of our parade, is that the program might not crash when the error occur, it will have a strange and bizarre behavior (sometimes it is just better to crash).

Although I referred only to memory corruption, all of the arguments I presented here are valid in the case of data corruption too.

2. Silent Failure

Silent failure may be caused by the irresponsibility of the programmer. Don’t catch every exception everywhere if you don’t handle the error properly, it might lead to data or memory corruption… How many times did you see these kind of code?

private double importantData;
private void ChangeData(int a, int b)
{
    try
    {
        importantData = a / b;
    }
    catch (Exception)
    {
        // You may log here...
    }
}

This code will make a “divide by zero” error go away, but it will cause a much more serious error – data corruption. If you don’t have anything important to do with this error, let higher layers handle it (if you want to catch the exception for logging purposes, you can add a throw; statement after logging).

3. Dead lock

From Wikipedia again: “A deadlock is a situation wherein two or more competing actions are waiting for the other to finish, and thus neither ever does.”

Multi threading or multi processing is very hard environment for debugging! When those kind of error occurs, it might be very difficult to find the problem and fix it. Why? because those errors might happen occasionally and under very special circumstances, and because they might not occur while you debug (the timings are changed…).

The only consolation with those bugs is that they show up immediately, unlike the data & memory corruption and the silent failure errors.

4. Memory leak

Guess what? From Wikipedia again: “a memory leak is a particular type of unintentional memory consumption by a computer program where the program fails to release memory when no longer needed. This condition is normally the result of a bug in a program that prevents it from freeing up memory that it no longer needs.”

Those errors are really annoying and dangerous, you might not know that you have a problem until you do some stress tests, if you do them at all. Fortunately, when realizing that these problem exist there are memory profilers which can help solve the leaks. If you are using the .Net environment, here is how to find memory leaks with the CLRProfiler.

5. Unhandled exceptions

Those are the easiest, they are raised immediately when the error occur and you can easily handle them.

This is it! Would you make the list any different? Did I forget some major error category? Have your say…

Tags :

One Response to “Software Errors Parade”


  1. Mark Kamoski

    Said on November 17, 2008 :

    What about business logic errors?

Post a Comment