After my message yesterday, I updated my strategy a little bit.

Yesterday, I added the code to my global error handler that is always called by vbWatchdog. I created a Call Stack string variable every time there was an error regardless of how it was going to get handled.

This worked for the time being, but I discovered that I had some routines that were using error handlers to ignore certain errors. Say to see if a file exists, a routine is trying to access the file properties and knows it’s not there if it gets a certain error. Generally wouldn’t be a big deal for single cases like this. I timed the Call Stack traversal and it was taking it about 0.002 – 0.005 seconds on my dev machine. That’s not too bad, but I am sometimes looping through objects and determining whether a section exists in a report by checking an array from 1 to 100 on the section number. This generally produces upwards of 90 errors and can end up running several times. It is pretty unnoticeable when I’m using it without the call stack, but as soon as I added the call stack I noticed a significant slowdown in the form of multiple seconds due to the sheer number of times this error is being handled and the call stack string being built, and it wasn’t been used because it’s a throw away error. (Yes, I’m sure I could work on the efficiency of that loop, but that will be for another day).

In general, I decided it would be better to create the call stack only when needed. This meant I needed to pass the ErrCallStack object to the routine that does the logging which is in the library database. So I got that all set up and tested it and I got a vbWatchdog error stating that I was calling ErrCallStack outside of the global error routine. I initially thought all was lost, but then I discovered that what was actually throwing the error was only when I tried to retrieve the code line. Ok, so I left the code as is and removed the portion of the log with the actual code line for now. That will still allow me to lookup what is running by module name, procedure name, and line number. This will still give me a major leg up when debugging this application.