When exactly am I required to set objects to nothing in classic asp?

Question

On one hand the advice to always close objects is so common that I would feel foolish to ignore it (e.g. VBScript Out Of Memory Error).

However it would be equally foolish to ignore the wisdom of Eric Lippert, who appears to disagree: http://blogs.msdn.com/b/ericlippert/archive/2004/04/28/when-are-you-required-to-set-objects-to-nothing.aspx

I've worked to fix a number of web apps with OOM errors in classic asp. My first (time consuming) task is always to search the code for unclosed objects, and objects not set to nothing.

But I've never been 100% convinced that this has helped. (That said, I have found it hard to pinpoint exactly what DOES help...)

Answer 1

This post by Eric is talking about standalone VBScript files, not classic ASP written in VBScript. See the comments, then Eric's own comment:

Re: ASP -- excellent point, and one that I had not considered. In ASP it is sometimes very difficult to know where you are and what scope you're in.

So from this I can say that everything he wrote isn't relevant for classic ASP i.e. you should always Set everything to Nothing.

As for memory issues, I think that assigning objects (or arrays) to global scope like Session or Application is the main reason for such problems. That's the first thing I would look for and rewrite to hold only single identifider in Session then use database to manage the data.

Answer 2

Basically by setting a COM object to Nothing, you are forcing its terminator to run deterministically, which gives you the opportunity to handle any errors it may raise.

If you don't do it, you can get into a situation like the following:

• Your code raises an error
• The error isn't handled in your code and therefore ...
• other objects instantiated in your code go out of scope, and their terminators run
• one of the terminators raises an error
• and the error that is propagated is the one from the terminator going out of scope, masking the original error.

I do remember from the dark and distant past that it was specifically recommended to close ADO objects. I'm not sure if this was because of a bug in ADO objects, or simply for the above reason (which applies more generally to any objects that can raise errors in their terminators).

And this recommendation is often repeated, though often without any credible reason. ("While ASP should automatically close and free up all object instantiations, it is always a good idea to explicitly close and free up object references yourself").