I'm working on some code that checks all Resource documents in a view. For each Resource document, the code creates a custom LotusScript class called "Resource". If the Resource document has a Request child document, the code instantiates an object based on a custom LotusScript class called "Request". (Both the Resource and Request objects are defined as Variant, by the way.) After processing the "Request" object, the code attempts to delete the "Resource" and "Request" objects. The problem is that sometimes there is a Request object and sometimes there isn't. For example, if the code attempts to delete the Request object before it has been instantiated, Notes returns the following error:

Error # 193 - Illegal DELETE

If the code attempts the delete the Request object after it has been instantiated and deleted, Notes returns this error:

Error # 91 - Object variable not set

The answer is to check to see if the Request variable is an object first, then check to see if it is Nothing, like this:

If ( Isobject ( res ) ) Then
	If ( Not ( res Is Nothing ) ) Then
		Delete res
	End If
End If

Of course, the obvious question is why I'm bothering to delete these objects at all, when LotusScript automatically deallocates objects for you. Well, I thought I'd be a responsible citizen and immediately clean up after myself when instantiating objects within a loop. Call it Post Traumatic Stress Disorder brought on by not calling recycle() on Domino objects instantiated within either a for or a while loop within Java code. I know the two languages are completely different and handle object deallocation differently, but I'm concerned with assuming Notes will do the right thing and having my application crash the server once its in production and being used by 2k employees on a daily basis. Also, the example code contained within "Appendix B-2: Dynamic Script Library Loading" of the Performance Considerations for Domino Applications IBM Redbook show the custom object being deleted, and I'm assuming that that's being done for a reason...

No comments.