Skip to main content
    Country/region select      Terms of use
     Home      Products      Services & solutions      Support & downloads      My account     

developerWorks  >  Lotus  >  Forums & community  >  Best Practice Makes Perfect

Best Practice Makes Perfect

A collaboration with Domino developers about how to do it and how to get it right in Domino

An uninformative error messageThe "Service Engine" light in my wife's car came on yesterday. This was vexing, as we'd just brought the car in to our favorite mechanic to satisfy the car's previous complaint, and they ended up replacing a bunch of sensors. So we brought it in again, and they hooked it up to their computer to read off the error code that the car's computer had recorded. Unfortunately, it was a generic code that didn't really convey any information, and the car's computer didn't keep a record of what its sensor readings were that led it to post the error, and it seemed to be running fine, so that's the end of it as far as figuring out what the problem was. They didn't charge us anything (this is one of the reasons they're our favorite!).

Excuse me while I rant for a bit. I can understand why the car would not display details about the problem on the dashboard. After all, most end users are not equipped to deal with details, and text displays are expensive compared to one light bulb to light up "Type Mismatch" -- oops, I mean "Service Engine" -- on the dash. But how much memory can it take to store a little explanatory message and a record of the sensor readings at the time, so that the technician can pull it up with their special equipment? Now we just have to expect that the light will come on at intervals, and we have no way to tell whether it represents a real problem without taking it in.

With PCs, of course, displaying extra information costs nothing and we have lots of ways to log data when an error happens. So we can expect that applications running on a PC will provide much better explanations, and will record lots of information to allow the mechanic -- probably you, gentle reader, in the case of Notes applications -- to determine what went wrong and fix things so it doesn't happen again.

Alas, the situation seems to be otherwise. Many applications out there in NSF-land do nothing about trapping and logging errors, despite the availability of the useful free tool OpenLog on, which makes this a breeze. Even if you don't go whole hog on implementing a logging solution into your apps, you can at least write your formulas and LotusScript code to replace the generic error messages generated by Notes with ones specific to your application, and (for LotusScript) to display the call stack and line number so you can determine how you got to the point where the error occurred. You could even display the values of some important variables, so that when the user emails you the screenshot of the error dialog, you have something to go on. I wrote an article for dW about Debugging Domino Applications (part 1 and part 2) with information you might find useful in this regard.

I'm pleased to report that our template developers here in Lotus are also getting into the action -- version 8.0 features distinctly improved error reporting in some of our templates, especially mail. We're discussing how to make it even much, much better. After all, when the Notes client crashes we get an error report here at IBM. Why shouldn't we get an error report when someone has a problem accepting a calendar notice -- or whatever? And why should they have to do a screen shot? The help line should already have the information sent to them automatically. Why should they even need to call it in? Lots of times, if people aren't blocked by an issue, they see no reason to should waste their time calling someone -- and so it can persist as a low-grade annoyance for a long time because nobody knows it needs fixing (or realizes how often it really occurs).

Andre Guirard | 6 April 2007 08:41:45 AM ET | Caribou Coffee, Plymouth, MN, US | Comments (2)

Search this blog 


    About IBM Privacy Contact