I'm in an Access 2003 db. I have a command button event in a form with a robust error handling routine. Some errors are trapped and dealt with there, but the majority will logged to a table so I can review them later. The routine loops through a table and runs 50 or 60 reports. Some of the reports are run from function calls in a module. The name of the function is stored in a the table I'm looping through. There are about 30 functions in the module that may or may not be called. I want all error handling to be sent back to the calling procedure in the form. I don't want to have to duplicate the error routine in every procedure in the module. In regular VB, the calling procedure would handle the error if the called procedure does not have an error handling routine. It doesn't seem to be working like that in Access VBA. Has anyone else encountered this, and what can I do short of adding error handling to every function?
Error Handling
- Thread starter GrexP
- Start date
If you want to throw the error upward to the procedure that called the function, don't put any error handling in the function. If you still need to have some error handling for the function itself and throw the rest upward, then you want to use "On Error GoTo 0" wherever you do not need to handle it within the function. Not very sophisticated, but VBA 's error handling isn't all that great.
Right, that is how it is supposed to work, but its not. There is not one "On Error" line in the entire module, and all functions in the module are called by the event in the form. The event in the form has the error handling, yet the functions in the module break on error. The error is not being passed back to the form's event.
The only thing I can think of is that the problem is because I am calling the functions with the Eval() function. The function names are read from a table and passed to the Eval() function in a varaible.
That is my only guess.
Good guess, but I check that. It is set to "Break on unhandled errors". I even shut down Access and restarted thinking maybe Access was "lost". Same behavior.
Huh.
Two more things to try.
1) Try to step through the code from the start to end. Check the err object at points. Try to throw an error by inserting "Err.Raise 11" and see how it handles the error.
2) Remove the Eval() and see if behavior changes.
Two more things to try.
1) Try to step through the code from the start to end. Check the err object at points. Try to throw an error by inserting "Err.Raise 11" and see how it handles the error.
2) Remove the Eval() and see if behavior changes.
Yea, it is something with the Eval(). It is like passing the function through another compiler or something and the stack order gets lost. If I call the function in traditional manner, in code, and comment out the Eval() call, the error handling works as you would expect. The calling procedures error handler deals with the error.
Back to the drawing board.
Back to the drawing board.
I just read the Eval documentation, and wondered if maybe because of the nature of function (e.g. it tries to evaluate a data that isn't necessarily the right data type and perform some kind of operation on the data that would otherwise throw an error) it behaves differently.
That said, I didn't see why I would want to use eval(); If I can't be sure of data type, I'd use typecasting (e.g. CInt(), CByte(), CLng(), CString(), etc.) and of course use SQL to perform operations that can't be done natively in VBA.
That said, I didn't see why I would want to use eval(); If I can't be sure of data type, I'd use typecasting (e.g. CInt(), CByte(), CLng(), CString(), etc.) and of course use SQL to perform operations that can't be done natively in VBA.
