Object Variable Not Set with Custom Class

HCL Domino Domino Forum
1

I have inherited a database that uses a number of custom classes and unfortunately very little error trapping. Recently I have been encountering an intermittent object variable not set message for some users. Users are working over a broadband connection onto the server, which may be of relevance, although there is no evidence of connectiviy blips.

A number of pieces of script call functions that call the constructor for a custom class. The constructor (e.g. dim comLine as New CommitmentLine) then calls a constructor for a Global class. By means of some error trapping and defensive coding that was added, I have identified users are receiving object variable not set messages in the instantiation of one of the two objects for the custom classes. These constructors capture the current document and details of the current user’s environment, so there is nothing that should generate an object variable not set message. One point of note is that there are no destructors for the custom classes.

There are a number of best practice improvements I will be making - the Global class has not been used since before I inherited the database, so I will be taking that out; I will be adding destructors to all classes, in case memory is the issue; I will be ensuring the functions abort if an error occurs.

I also know about the issues with object variable not set messages when opening a document from a link in mail. That is not relevant to this scenario.

These improvements will at worst mitigate the problem, at best possibly solve it. My hypothesis is that memory is the issue, but I have been unable to find any evidence to support it. My question is has anyone else has had issues with strange object variable not set messages when using custom classes if objects are not destroyed after use?

Thanks

Paul

2

Subject: Object Variable Not Set with Custom Class

3

Subject: RE: Object Variable Not Set with Custom Class

Adding the error trapping would indeed be the most desirable option, but the customer is SOX-compliant, so any changes have to go through rigorous testing by their internal IT and users before going live. So it’s quite painful to get error trapping into live to try to diagnose a problem that then still needs fixing.

On reviewing the error messages I do get though, I found the first class it goes into does have error handling. The OpenLog message stack doesn’t mention this class, so everything suggests it’s not getting that far. A recompile didn’t clear the problem. The script library used in the form is an old one, which references a second script library, which references a third where the relevant code is. I don’t like to give up on logical explanations, but it sounds like there is a corruption somewhere, so I think I will try error handling at all levels, referencing the relevant script library directly and replacing the design with a blank template before refreshing.