Error handling

[Ari]

How much error handling should you build in? For example, I have a very simple program that takes one sort of ID and converts it to another in about 15 separate stages. Should I build in error handling at each stage (similar to below) or only at the places where it's highly likely to fail after bad data?

else {
    print STDERR;
die ("Unable to proceed.  ID may be invalid.  Exiting.\n");

(Initial input and the first calculations at the main concern - after that, there's almost no chance of error.)

I don't want to overdo it, same as I don't want to overcomment, but I also don't want to leave later maintainers wondering why it wasn't set up properly to start with!

[GrandFather]

If your error messages are as shown keep them to a minimum. They don't help the maintainer because they don't describe the details of the problem and they don't help the user because they don't describe how to avoid the problem.

Decide who the error messages are for and make sure they provide the best possible information for the audience. For a user that means describing the nature of the problem and how to fix it. For a maintainer that means describing as much of the pertinent context as possible so further debugging sessions are less likely to be needed to diagnose the problem.

User error messages are likely to be confined to areas of the code validating input. Maintenance error messages are likely to be sprinkled through the rest of the code as a sanity check and in place of a comment describing the expected outcome of steps. A test and die that checks an outcome is both documentation and sanity checking.

[choroba]

It really depends on many things. If, for example, the result is used only for an application that provides a progress estimate to you, almost no error handling is needed at all. If a wrong ID can spoil the data and destroy weeks of measuring in a special lab, you have to handle every possible problem.

Check for errors as soon as you can detect them - it also helps in fixing the data (you do not have to reverse-engineer the original problem from a wrong output).

[Ari]

That makes sense, thanks. In this instance, realistically the only actual chance of error is the user inputting something wrongly in step 1. By the time it's gone through steps 2-4 (which do have checks in place, and I'm working on verifying the input during step 1) it's just following a long-established business process (which has been working flawlessly for, oh, ten years or so).

Followup question: is there such a thing as too much error handling?

[chromatic]

... is there such a thing as too much error handling?

Yes. Does it make the code more difficult to maintain? Is it too expensive in terms of resources?

I spend most of my error handling budget at the edges of the application, where data can come in or where it's easy to misuse an API. I spend a lot of time making sure it's difficult, if not impossible, to misuse an API.

[Marshall]

My philosophy is to validate the heck out of anything the user has to say. Concentrate all of the validation checks into one place and give the user actionable information about what is wrong and then assume in the rest of the code that the input is valid...well sort of...I give an example of some code that I am working on...

sub compare2records
{
    my ($x, $y) = @_; # $x and $y are array refs to DB records
    my $result =0;
    
    #typical message might be.... 
    #Argument "13ND" isn't numeric...blah...blah
    
    local $SIG{__WARN__} = 
    sub 
    {
        my $msg = shift;
        print STDERR "*******\n";
        print STDERR $msg;                 #has a \n in $msg
        print STDERR "current DB record:  id=", $x->[$dbc_id]; 
        ...other complicated info for developers... 
        print STDERR " other DB record: id=",$y->[$dbc_id],"\n";
        print STDERR "*******\n";
    };
    
    ... complex comparisons happen here....
    ... a non-numeric field in the DB that should be numeric will
    ... cause an error and will be intercepted by the SIGNAL handler
    ... these are messages intended for the develop team ...
    ... the user shouldn't see this, it means we screwed up on
    ... data validation and it is "our" problem, not a user
    ... problem! We have to fix code, this is past user has to
    ... fix his/her input! A user input error should not have
    ... gotten this far!
}

The idea here is that this SIGNAL handler should never be executed. If it does execute, then the info is for the development team and we have to fix a problem regardless of the user. This is an example of "OUR" problem versus "YOUR" problem as a user. We have "our" problem because of some issue that we failed to tell you, the user about further upstream.

So, this is a bit of a mix. The further down in the code that an inconsistency is found, the more detailed and more cryptic the error message will be. Find the user input errors early. I don't expect the user to know what the heck an error between 453,203 and 129,385 means - something like that means that we (the SW team) screwed up.

In this application, I get 900+ files from 900+ sources, using 80+ programs to generate the files. Stuff happens. It is not possible to herd 900 chickens into the same roost without good SW or a lot of sheep dogs! Mixed metaphor, but I think you get the idea.

[Ari]

I think this approach was what I was leaning towards. I'm still building the validation for the initial input. After that, the program *should* work correctly. If the user (or, eventually, file) contains the wrong initial ID then the resulting answer won't be what they were expecting, but it will be correct. (At least, that's my hope. This is my first project, so I'm building it in stages and learning as I go!)

[AnomalousMonk]

... after that, there's almost no chance of error.

"Unfortunately, Dave, that sounds a lot like 'Famous Last Words'."