What Every Computer Scientist Should Know About Error Handling

[rkarman]

Error handling assumes there are errors in your code, this is of course a bad assumption and all time spend to making error handling should be spend to error checking instead, well this is my view at least.

why do i make such a wild claim that error handling is not a good thing?
well in my oppinion there are 3 types of errors:
1 unforeseeable and unrecoverable errors, in this grou you would have for instance the "out of memory" exceptions. well what can you do if this happens? not much actually, most likely you don't have the memory to do any recovery to begin with.

2 errors that function as output of an function, in this group you would have an "read only" exception on an file operation. the exception is thrown as kinf of a return value/status. this kind of errors should be handled, but can be argueed to be more like status messages or return values and would always be mentioned in documentation.

3 foreseeable erros, in this group you would have errors like "divide by zero" or "null reference" exceptions. basically instead of of trying to catch them later on it's better to check for these to go happen up front. if you forget to write the check and handle things properly before doing an divide it is better to not try to recover this later on. trying to recover would only make it easier for the bug to slip through your tests and checks and for the automatic recovery to make your program behave odd.

of course you should handle errors somewhere (on the highest level for instance) to output them to a log or display them on the screen instead of letting the code really crash. the point is though, don't write to much error handling! (like in every function or method) it's one of the biggest mistakes you can make in getting bug free code (i know it sounds odd, but try it sometime)

[Carol Haynes]

1 unforeseeable and unrecoverable errors, in this grou you would have for instance the "out of memory" exceptions. well what can you do if this happens? not much actually, most likely you don't have the memory to do any recovery to begin with.

Actually that is one that should be trapped and processed - even if it is only to save your work and exit cleanly.

One of my pet hates is software that just pops up 'out of memory' and exits without any user assistance ... I have come across a few of these apps.

[rkarman]

yeah i agree. i meant you should not handle that on each function call though but on the highest level possible in your code. the idea is not to have no error handling at all, but just one error handler at the top most level.

this post was more to warn people against writing try cach around everything they do.

[Carol Haynes]

quite - I agree with that

[rkarman]

i just realize i should give an example of why it is bad

consider the following code (in c#):

Code

string getnode(string xpath)
{
        try
        {
                return myconfigfile.SelectSingleNode(xpath).Value.ToString();
        }
        catch
        {
                return "";
        }
}

at first it looks like this is a good routine (a lil lazy written maybe) because whatever happens you always get an empty string instead of an null pointer exception. even if the node did not exist.

but what happens if you feed an invalid xpath string? the routine also returns an empty string! this can cause a lot of things to go wrong in your code, but not at the point where it fails, but later on where the results are used of your code that failed. debugging those errors is a crime.

now look at this code:

Code

string getnode(string xpath)
{
        Node mynode = myconfigfile.SelectSingleNode(xpath);
        if (mynode == null)
                return "";
        else
                return mynode.Value.ToString();
}

this also returns an empty string if the node doesn't exist, but if you feed it a wrong xpath string this code will crash. so the first time a developer runs his code that calls this function, he will get an warning about invalid xpath syntax.

the try catch unnecesarrily catches all or a subset of errors. by instead checking for the speciffic anticipated situation we were not caught off guard when writing some flawed xpath string.

of course there are situations where this example would not apply at all, but i think it is a good thing to not to write code this way by default


hope this clarifies my view a lil more