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.

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).

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?

... 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.

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!
}
[download]

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.

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!)

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

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