Handled error break hammers local storage
I am enccountering something that has been evolving from a simple annoyance to a problem that I will have to deal with.
I am working in Access 2007/accdb for clients (although I have 2010 32 bit on my home machine).
If my apps break on a handled error, it appears to hammer many, if not all, of my public variables and custom classes.
This is a PITA for me while developing, since I find that I have to close the app and then re-open it to reinitialize the objects. In production it means that a user should probably close and then re-open the app if they ever get an error message; which lacks grace.
I incorporate message handling in every subroutine and function except class modules, where I apply situational discretion as to how an error is handled. I have a public HandleError function that takes care of the paperwork.
My default is to have my errors break in class modules, which I enforce when I open the app with the following:
Application.SetOption "Error Trapping", enmBreakInClassModules
Is this normal behavior? For some reason I don't recall this being as much of an issue in years past. My impression is that this is something that has come more to the fore in 2007 and 2010.
I am working in Access 2007/accdb for clients (although I have 2010 32 bit on my home machine).
If my apps break on a handled error, it appears to hammer many, if not all, of my public variables and custom classes.
This is a PITA for me while developing, since I find that I have to close the app and then re-open it to reinitialize the objects. In production it means that a user should probably close and then re-open the app if they ever get an error message; which lacks grace.
I incorporate message handling in every subroutine and function except class modules, where I apply situational discretion as to how an error is handled. I have a public HandleError function that takes care of the paperwork.
My default is to have my errors break in class modules, which I enforce when I open the app with the following:
Application.SetOption "Error Trapping", enmBreakInClassModules
Is this normal behavior? For some reason I don't recall this being as much of an issue in years past. My impression is that this is something that has come more to the fore in 2007 and 2010.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Todd,
<<I think this is happening even if I don't do a reset; but, to be honest, I'm not sure (knowing myself, you've probably identified what it is I've been doing). >>
It should not be happening if you are not resetting. Simply breaking execution is a pause (you have a breakpoint on the line, have told VBA to break, or have a STOP in the code).
When your at a break, you can hit F8 to step through code line by line or F5 to simply continue.
But if you do Run/Reset off the menbar or hit the Square on the toolbar, then your resetting executiona nd everything will clear.
Jim.
<<I think this is happening even if I don't do a reset; but, to be honest, I'm not sure (knowing myself, you've probably identified what it is I've been doing). >>
It should not be happening if you are not resetting. Simply breaking execution is a pause (you have a breakpoint on the line, have told VBA to break, or have a STOP in the code).
When your at a break, you can hit F8 to step through code line by line or F5 to simply continue.
But if you do Run/Reset off the menbar or hit the Square on the toolbar, then your resetting executiona nd everything will clear.
Jim.
ASKER
So...
I'm going to accept your answer, and keep your advice in mind. If my experience differs. I will revisit.
Thanks,
Todd