Custom 500 error page question

closing objects, recordsets, etc.

[mattglet]

When you have a custom HTTP 500 error handler, how do you go about making sure all your previously opened recordsets/objects/connections/etc. are closed properly?

It would seem to me that once you hit a 500 error, you have no opportunity to close any of the previously opened objects, eventually causing memory leaks.

Any ideas as how to effectively remedy this?

[mattglet]

*bump*

[Krapulator]

You need to build error handling into your asp routines. Then if there is an error, rather than popping up the 500 error screen, you can explicitly close whatever objects are open and then handle the error smoothly.

Google for "error handling in asp"

[mattglet]

I am well versed in error handling.

My question is how to deal with the unexpected, while still using a custom 500 page.

[Krapulator]

Correct me if I'm wrong, but if you are using
<%
On Error resume Next
%>
in your code, then when the ASP parser hits an error, it will skip over the error and continue processing the page. So if your code is correctly closing your objects after you use them, then you do not need to worry.

Your error handler can then do what it needs to do (eg send you an email or whatever) and then you can response.redirect (or server.execute) to your custom 500 page.

[aspdaddy]

But I think that is a different solution altogether from using custom 500 error pages to handle errors and clean up.

The last suggestion is similar to an approach I use, coding this after every line that could create an error :

if err.number<> 0 then
raiseError err.number, err.Source, err.Description

It closes the objects OK but may report the wrong error if you havent trapped all possibilities.

I dont like using on error resume next - a 500 error handler would be much better.

[mattglet]

K-

I totally understand where you are coming from, but what about the times where errors happen before you can close the object? You're thinking of "the perfect world" a little too much.

My site gets over 8 million page views a week; I've seen just about everything happen. We currently have a complete error trapping solution in place while using On Error Resume Next, but I hate it (it's legacy) for reasons such as aspdaddy gave. I'm looking for other avenues to take, one including a custom 500 page.

I'm not looking for a way to NOT use a custom 500 page, I'm looking for a way TO use a custom 500 page. I'm just finding it hard to believe no one here has encountered this before, and has either a "Yes it can be done", or "No, I've tried this and it doesn't work".

K- You've definitely got some good ideas, keep them stewing.

[TheNige]

I just don't see how a custom 500 would even know what objects you had used on the page to be able to close them unless you were using things stored in application scope.

You are better off trapping your errors at the page/routine you are calling them from and do the clean up there.

That's one nice thing about .Net...garbage collection.

[aspdaddy]

But does ado.net automatic garbage collection and the page_error event handle unhandled errors? I diddnt think it guranteed it, please correct me if im wrong :)

As you suggest the only way to handle the unhandled seems to be with an appication context that has access to the connection pool / MTS.

Maybe a bespoke service ruuning that periodically checks the number of objects not pooled correctly... but isnt that what MTS objects, connectioon pooling and object brokering are all meant to do anyway?

[TheNige]

.Net garbage collection is built into the CLR. From what I know it will look at all objects and then dispose of them when needed....not necessarily at the exact moment though. But using Try Catch blocks makes it easy to catch all exceptions in .Net.

But the original poster is using classic ASP right?

Even Microsoft has put out recommendations to schedule application restarts in IIS to take care of memory leaks, free up memory, etc. So even if you can't catch every single exception and close all the connection, destry objects, etc. it would eventually be freed up on the restart. It sounds like a poor work around to me though but it would work if you are that worried about it.

[mattglet]

Well, we do actually have a scheduled reboot every 2 months, so that could be a possibility.

I'm still not sold yet though that this can be done (yes, classic ASP). Oh well.