Premise Persisted timers that reference deleted objects

As part of my work described in this topic http://www.cocoontech.com/forums/index.php?showtopic=15317 I've noticed that if I restart the SYS service (prkernel) while I have a timer pending, the timer still exists when prkernel restarts. This alone is not a surprise I suppose, but it does lead to a problem if the "this" object referenced in the timer script is no longer a valid object, and that is indeed the case when the object is a WebSession object. So when the timer finally fires, it causes a runtime script error.

I can imagine a similar design problem with other timers and the objects that the timer script references. Is there a particular design or coding technique to avoid this problem? For example, is there a way to indicate that a timer should not be persisted?

"on error resume next" ensures the call will fail quietly. Here's an example:


If the target object with an "Update" property no longer exists, setting "Update" to True will not cause the script interpreter to halt.

Thanks! This certainly does the trick. That's just another example of me being unfamiliar with VB (coming from a C/C++ background).

The only thing I don't like about the solutino it is that in general it could hide bugs in code. For example, there could always be some other bug in my code causing "this" to be invalid. The failure could be harder to debug since the manifestation might just be some session not going back to the default page rather than a script error closer to the point of failure. I think good code design generally would not leave timers running that reference invalid objects.

I wonder if there's a way for me to somehow keep a reference on the session object anytime I have an timer scheduled, preventing this object from being deleted until there are no timers. Perhaps as simple as setting some class property to reference the session object. Maybe I'll experiment with this.

Anyhow, it's all that important in the end.

Frank Y said:

... I think good code design generally would not leave timers running that reference invalid objects.

Click to expand...

What you're looking for is an event that occurs when an object is deleted. It could be used to perform housekeeping (i.e. delete existing timers). The only one I know of is the "ChildDeleted" event. It allows for the textbook approach of performing actions when an object is deleted.

In practice, I've found it to be less than satisfactory because it is invoked only when a child object is deleted. If an end-user deletes a driver object, without any child objects, "ChildDeleted" never occurs.

If you want the timer's payload to do more than simply suppress the error, you could have it check Err.Number and react accordingly.

http://www.devguru.com/technologies/vbscri...ickref/err.html
http://blogs.msdn.com/ericlippert/archive/...t-part-one.aspx
http://blogs.msdn.com/ericlippert/archive/.../09/227461.aspx