How to Handle Errors(Basics)

Have you ever debugged for hours to find a bug that is caused because deep down in a library there was an error which wasn’t thrown but an error code was passed up? I have! I tried to read a file which is divided into rows and columns. The chief architect had built a little DLL which reads the files and if it doesn’t work or something unexpected happens it throws an Exception. One of the senior developers wrote a wrapper around that library (C# wrapper around a C++ DLL) to handle the calls. But instead of throwing the exception an error code was passed when something went wrong.

I am not against error codes but they have certain downsides. First of all, you don’t get the error if you don’t check for it. So in the case of an error, you have to handle the flow of your application yourself instead of handling it only where appropriate.

Let's get the language straight / What is an Exception anyway?

In the section above I wrote about errors and exceptions. There is a difference between both but first of all, let's focus on our day to day use of the words. An error is a mistake that happens during the execution of a program. In the day to day language, one normally speaks of an error if the program won’t execute in a way which the programmer or user expected. An error might occur if the program is in an exceptional state, which leads us to exceptions. An exception is something that is not the norm. An object might be in a state of being normal or the object has an exceptional state which means something has to be done to get back to the normal state. So I am not talking about exceptions in a way of the class type Exception but rather an Exception in the normal language use. Exceptions divide into two divisions

  1. Expected Exceptions
  2. Unexpected Exceptions which shouldn’t occur

So in this blog post, I will use the words exception and error most of the time interchangeable. In the section where we talk about the Class Exception, I will have to make a difference and concentrate on the language used in this context.

Let’s look at an example

There is an object Employee which is in a state and has a standard behavior The standard behavior is to stand up in the morning, shower and then take the fastest possible way to his workplace. Now let’s assume the Employee is in an exceptional state(for example he is ill). He might stand up, shower and then try to go to work but his body says, “no you shouldn’t go to work, you should go instead to the doctor, etc”. And then there is the unexpected Exception which shouldn’t ever occur. The Employee wakes up in the morning and is in the state of being unborn <- this is very unexpected isn’t it. So lets recap:

Normal The employee is healthy Standup, shower and go to work
Expected Exception The employee is ill Stand up, maybe shower and go to the doctor
Unexpected Exception The employee is unborn/dead Stand up?

Two extremes of Error Handling

So what are our option to handle errors?

Don’t give a damn

That’s right, don't give a damn! This is by far the most common error handling mechanism that you can find but it should be on the other side of the spectrum. Most of the time you shouldn’t use this mechanism but in some environments, it seems to be legit. Say for example you have a Webcam that captures 10 images per minute and displays them in an application. If one out of those 10 images fails being captured than you might as well show the old one until a new one is shot. The UDP protocol handles “errors” like this. When handling errors like this I would argue that you wouldn’t call them errors or exceptions.

Log the exception

You can write log files to which you push the error messages and so on. This method is more of an addition to the “don’t give a damn” than a full substitute.

Shut down completely

If the method is security critical just abort if something wrong is found. Say you are writing an application which handles the temperature of an oven. A thermometer tells you if you have reached the right temperature. What should the program do if it doesn’t get any values from the thermometer? Hopefully, the program will shut down because if it doesn’t shut down the chances increase every minute that the building in which the oven stands will burn down. I would always choose shut down over burn down.

Two sides of a coin

I have picked the two extremes of possibilities to show that picking the right error Handling mechanism is not always easy. Whether you don’t handle it or shut down completely depends on the scenario of your program. There are for sure many more ways to handle an error but it all boils down to two extreme values. You can ask yourself has the program to be ultra stable which means never shut down and find a solution for all the errors that might arise or would it be highly risky to assume correct values and go on?

In most applications, the Errors will be handled via Error Codes or a specific mechanism provided by the programming language or the framework. One of the most important parts of Error Handling is, that you and your team decide which strategies and mechanisms to use and stick to it. Now let’s have a look at some specific strategies to handle errors/exceptions

Specific Strategies.

Error Codes

As already mentioned I am not a big fan of error codes because in the languages I mostly write I have the luxury of having Exceptions. In my opinion Error Codes make the code less readable and are far more often subject to wrong code. The code is less readable because it has many if-else constructs which clutter the code and if you forget an if-else construct the error is not being noticed until it is too late. In the case of my not properly read file it led to the problem that other files were not written correctly and some developers who used my tool wondered why values were missing. I haven’t checked for the error because I simply did not know that the method would return an Error Code.


If you are in a functional programming language you may already know monads. I rarely have seen them in my daily job and have never used them. I believe that they are a quite nice way to handle errors but I am unsure if they truly belong into an OO Language. If you have know-how in using them and you are familiar with them in C# then please feel free to write me an email and tell me about it :).


In my opinion, the best way, which means the most commonly used and readable one, to handle problems in your code are Exceptions. If your language of choice supports them you should definitely give them a try. The strongest point is that you immediately know that you are dealing with exception handling if you see source code in a catch block. This is very helpful if you maintain old code. I rather have an exception than a cryptic error code -312. What does -312 tell me about the state of my program? Well if you know that everything below zero is an error then you definitely know its an error. But you don’t know what kind of error. Hopefully, the developer provided a list of those error codes with matching descriptions what they mean. But where are they written down? In an enum in the class where the error occurred? Great then we have to have a reference to that Class… yuck. Maybe in another class on the same level, or up high in the library tree or maybe down the library tree? Many questions for a case which could be easily handled by the build in mechanisms. But even if he did provide a list in a good place, do you know if it was maintained or not? maybe the developer wrote the initial code and then quit the job leaving behind a junior developer who didn’t know better than to add new error codes without editing the documentation. The boss pays for working code and not for working documentation and as a junior developer you may not have the experience to know better and even if you have the experience you may not have the guts to stand up and explain to your boss that you can’t write code right now because you have to edit the documentation. Either way, the probability is high that you either don’t know what the error code means and if you know you still don’t know if it really means what the error code tells you.

Wouldn’t it be nice if the error Code had some kind of tag or something where you could read what the problem is and where it happened?

If you said yes, then you might like the concept of the Exception class. Exceptions have a descriptive type, they have a stack trace and they come most of the time with a neat little text telling you what you did wrong or why the method failed to execute.

Why are Exceptions a good concept

Exceptions are descriptive, they tell you why the exception occurred. Exceptions give you the chance to fix the error on the right position. You don’t have to pass the error Code from down below up to the UI Methods and then interpret the error code there. The exception occurs and you catch it in an appropriate method up in your code. The exception will bubble up and you can handle it where it is needed and not in every method along the way.

Handle Errors where they occur?

I have seen source code which handles the error right where it happened and the developer felt ultra smart doing so. Every time a problem would arise he asked the user what to do. This seems to be a good idea until you realize that you shouldn’t have UI Code deep down in your business logic. UI Code in the business logic couples the code to an environment and this shouldn’t happen. Now every time a developer wants to use some logic in his cool new REST Webservice he has to reference and deploy some Telerik, devexpress, swing, awt, ShitUI.lib, BeautifulUi.dll or whatever. I hope this gave you a little bit of insight into error handling. This matter can be pretty complex in bigger architecture so the biggest points to highlight here are You and your team should have a clear concept of which error handling mechanism you will use If you can, give exceptions a try to see if they fit your needs

Have a great day and hopefully until next time


By the way, this is the Code (I altered it a bit) that caused my searching marathon. It is pretty straight forward. It checks if it has everything and then reads the RowCount. The bad part is where the exception is caught and nothing happens. You won't find such an error because you will have to check everything else first. Shame on my btw. I could have checked the logger, which could have prevented this long search.

public int GetRowCount ()
    if (String.IsNullOrEmpty(m_sGuid))
        Logger.Send(false, "Empty m_sGuid");
        return (-1);
    int iRet;
        iRet = GetRowCountG(m_sGuid);
    catch (Exception ex)
        iRet = -2;
        Logger.Send(false, ex.Message);
    return (iRet);
Go back
This page uses cookies: READ MORE ;