In my work I have come across numerous instances of 'lazy' error handling. By 'lazy' I mean doing as little if anything to distinguish between genuine errors and ones that might as well be turned into a warning.

In a typical web application, there are a lot of cases of invalid user input. Unfortunately, more often than not such exceptions are handled inappropriately at run-time. Here's an example. One particular web application that dealt with processing and displaying news items would always present a visitor with an error page whenever he’d follow a link with a ‘;’ at the end (e.g.;). This non-digit character would end up trailing at the end of the ‘id’ query parameter received by my script. Consequently, when plugged into an SQL query to retrieve article contents, nothing would be returned, resulting in an ‘article not found’ error page and a corresponding log entry.

By examining my web application logs and also checking pages for invalid URL links (with the ‘;’ at the end), I had a hard time figuring out where exactly those invalid URL links came from. To spare you some time and make a long story short, I did eventually discover one particular 3rd party opt-in email program that was at the root of the problem (hardships associated with the use of 3rd party tools well deserve a separate discussion ;]). For reasons not yet known to me, the program would include ill-formatted links in it’s bi-weekly newsletter emailed to our subscribers. This tool being somewhat outside of my reach (handled by our editorial / marketing staff), I clearly hand to handle the situation from my side as sensibly as possible.

Clearly my initial handling of the invalid article id was inappropriate. An extra non-digit character at the end of the id string does not warrant a critical error. Simply removing all non-digit characters from the id parameter value solved the problem, yet still let my code handle situations where indeed the id didn’t exist (expired article etc). So, the initial error handling was replaced with a simple warning log entry in case of a non-digit character in the id string, and an error log entry along with an error page for all other cases.

Obviously this is not something you’d call a hard-to-fix bug. However, I think it does point to one specific problem area in a number of web applications, or even system (back-end) tools. In my case, it did help me realize that I had many more similar situations where a critical error could be safely separated into lesser warnings and thus minimize affect on the end user (in my case, a user could still see the intended article despite of the invalid character). Certainly this involves more work for the developer and is not a consolation for many of us here who have been accustomed to cherish the virtue of ‘laziness’ ;-)

# Under Construction

Replies are listed 'Best First'.
Re: Sensible error handling
by Louis_Wu (Chaplain) on May 02, 2003 at 19:11 UTC
    Certainly this involves more work for the developer and is not a consolation for many of us here who have been accustomed to cherish the virtue of ‘laziness’ ;-)
    I guess more work depends on how broad your view is.

    If you just consider the work needed to fix these cases, then it's just work down the drain. If you consider the wider scope of what the users have to deal with, your work has done some good, even if you don't see the benefit.

    Broaden your view again, and you see that the tech support people and the editorial / marketing staff now won't have to deal with angry calls / emails saying "I followed your stupid link to your stupid site and it gave me a stupid error", so you have created a direct benefit for your company.

    Expand your horizons once more and you'll see that tech support / editors / marketing won't be beating on your boss's door and accusing you of having a stupid website which doesn't understand a simple link; now you get a direct benefit, a boss who isn't frustrated. :)

    And now you don't have to do more work to satisfy these people when your boss calls you on the weekend. :)

    Perl programming and scheduling in the corporate world, as explained by dragonchild:
    "Uhh ... that'll take me three weeks, broken down as follows: 1 day for coding, the rest for meetings to explain why I only need 1 day for coding."
Re: Sensible error handling
by crenz (Priest) on May 02, 2003 at 18:25 UTC

    AFAIK, ";" is a perfectly valid separator for parameters and can be used instead of "&" (eg. http://myserver/page?msg=Hello+World;empty=;number=0). So it seems your parameter parsing code has a problem as well -- the invalid URLs aren't.

    Apart from that, I second your statement -- it is often better to be a bit more liberal about validating your input than to throw unnecessary fatal errors at the user.

      I didn't mention it, but this web application was running on a Tomcat web server, which didn't seem to recognize ';' as a valid query parameter delimiter. Regardless of the fact the web app was coded in Java, this issue of improper error handling is universal. In fact, I found similar instances in my other Perl web applications as well. ;-)

      # Under Construction
        If you read the W3 standards on this you'll find that & is the incorrect and outdated delimiter and ; is the favoured and the correct option. Nice to know Tomcat keeps up with such standards. :)

        As a side note, the module has supported both since the first release. -- footnote #26.

        - wil