I typically find that the abilities of LotusScript almost always leave me wanting more. This is particularly true in the area of error handling.

I think most Domino developers follow a fairly typical path when learning to write error handlers.

• what errors?
• on error resume next
• on error goto ErrorHandler

The ErrorHandler typically comprises some number of the following: logging the type of error (err and / or error), where the error occurred (by line number or function name or both), and exiting. And this code in whatever form it takes, must be present in each module. Or so I assumed.

"When I was a child, I spake as a child, I understood as a child, I thought as a child: but when I became a seasoned programmer, I put away childish things."

For a couple of years now we've had lsi_info() and getthreadinfo() to help us provide some additional clues as to where a given error occurred. getthreadinfo() is pretty straightforward as it's actually documented. lsi_info() is where things really start to get interesting.

For example:

• lsi_info(2) - module name where the lsi_info() occurs.
• lsi_info(12) - calling module name where lsi_info() occurs.
• numerous others...

I have continued to use these functions in my usual error handling. a little more sophisticated, but ultimately not much better.

It occurred to me after testing some additional arguments to the lsi_info() function that there might be a wholly different and better way to do this.

The key to all of this is lsi_info(14) which provides a stack trace (v6 and later only). Thats right, boys and girls, a stack trace. No more push() ing and pop() ing module names into an array or list to keep track of a given error. Not only that, but since unhandled errors bubble up to the calling functions errorhandler the code to handle fatal errors (you still have to handle your non-fatal ones locally) can be put in only the top level module of a given piece of code (say Initialize for an agent)

It's not a perfect world. You'll need to format the stack trace before you present it to either your log or user.

Function Foobar()

'Error occurs here!

End Function

Sub Initialize()
On Error goto ErrorHandler
Dim errh as New customErrorHandler

call Foobar()

ErrorHandler:
call errh.ReportFatal() 'Gets handled here.
Resume ExitWithError
ExitWithError:
End Sub()

So generally I do not care for searchdomino tips. They tend to be a little basic, and the newsletters tend to be a little bloated with vendor speak. Despite that I was reading a recent submission ( a pretty intestesting article) when i get to the line:

On Error Goto oops

Can we not call identifiers what they are?!? This drives me just a little nuts. Im not suggesting that we adopt full hungarian, but if its an errorhandler lets call it that instead of oops.

By the way, If you happen to have seen my name in another recent searchdomino article, please do not allow that to influence your opinion of this post. The fact that they used both my name and my quote has no bearing whatsoever on my opinions.

er.... mostly. :)

So when I was at the "Meet the Geeks" event I sat down at the IBM... er... Ed Brill and Alan Lepofsky table and apparently someone gave Chris Miller a camera and i got caught talking to Alan. Or maybe he got caught talking to me.

Interestingly enough one of the topics was global privacy and how IBM was dealing with the latest opponent to collaboration. For the organization I work at I think this photo would have to have some kind of release. :-)

Dont you love progress.

Currently sitting in the Web 2.0 session Bob Balaban is presenting. Mostly just using Javascript and XML to make better UIs. My interpretation of that is... writing extra code to make up for what Lotus / IBM will not do with the Domino server.

As luck would have it I was approached by Matt Gervais from SearchDomino this morning to ask me what i thought about the conference.

In the process I asked him about the now infamous "Best practices for migrating LN apps to modern platforms" newsletter. Lots of coverage on it elsewhere. He went on about how the editorial staff is at the mercy of the marketers.

It seemed clear they took a beating over the whole issue. He even mentioned how people are dropping the subscription, the recent "call for experts", and eventually referenced a conference call between them and ed in a damage control context.

Interesting times over there at SearchDomino.

Bob Balaban: Doing really good web apps in Domino is possible, but it sure aint easy. You have to poke and prod.... it's a bitch.

A real live actual quote. I promise.

I'm in the Designer 8.5 commercial... er... session being conducted by Maureen Leland and Phillipe Loher.

• They announced the public beta of the the 8.5 Designer is a month away.
• They showed some of the eclipse editors (javascript, css, xml, etc)
• Xpages of course. Web 2.0 mashup controls. Pretty nice.

Observations: In typical IBM fashion they didn't put the perspectives available from the default UI. No buttons; you have to select something like tools/perspective/others... with no shortcut. :-)

Caught Bill Buchans session today: Advanced OO in LotusScript.

Interesting notes:

• .. notation for parent method execution
• Factory class for dynamic class loading via the execute command. really sexy stuff.

Good Stuff in the keynote. Lots of bling in designer 8.5 and Sametime updates.

More of the same from Connections and quickr.

Alistair Rennie almost slipped up and admitted they nearly waited too long to re-tool the designer. My current employment is in a place that is under siege by Sharepoint and the rabid m$ faithful.

Nearly? "Your product is only mostly dead..."

Developer jumpstarts are kinda lame this year.

Early Sessions

• Complete Guide to Domain Monitoring
• Sametime 8 Deployment and Upgrade
• Administration for Developers

• Comprehensive Guide to Policies
• Building a Java Foundation for Eclipse
• Coding in LotusScript: Core Elements

Caught the sessions that John Kidd is doing on Administration for Developers and then Java foundation for Eclipse.

No CertFX in the certification prep labs.