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