Error Handler Not Handling Error 91

[DB505050]

I have been reading up a little and it seems that this may be a bug....

Here is what is happening: I have error handling code that should avoid an error message.

The first time I have an error, however, it throws error 91: Object Variable or With Block Variable Not set

Then, any other time after that, the error handling code works perfectly.

What is even more odd: If I set a break point and F8 my way through the code, the error never shows up and the error handling code works perfectly.

Here is my code. I found this neat piece of code that gets me the subroutine name as well as object name and module name:

On Error goto errhandler

.....code stuff, and calling a function. The error is occurring in the function.

Exit Sub
errhandler:
strObjName = CodeContextObject.Name
Application.VBE.ActiveCodePane.GetSelection merr, nerr, xerr, yerr
strModName = Application.VBE.ActiveCodePane.CodeModule
strProcName = Application.VBE.ActiveCodePane.CodeModule.ProcOfLine(merr, 0)
Call ErrHandlerPublic(strObjName, strModName, strProcName)
Exit Sub

All variables above are defined as public variables. I tried local ones too and it made no difference.

When it throws the error and I hit debug, it highlights this:
Application.VBE.ActiveCodePane.GetSelection merr, nerr, xerr, yerr

But again, if I hit F8 it completes the code perfectly.

Any help greatly appreciated!!!!

 

[spikepl]

I suspect you have stumbled upon the Holy Grail of VBA - listing the stack from VBA.

Or perhaps not. VBE is the Visual Basic Editor and references to it would not seem to have any business in a normal operational application. This would also explain why it appears to work, when the VBE window is open. Check the source for your code: there should be some description of context and caveats.

To have the error handler refer to the routine in which the error is trapped, the name of the routine can be inserted manually or by the free MZtools http://www.mztools.com/index.aspx

 

[gemma-the-husky]

it's hard to tell without seeing the rest of the code, and this bit may not be the problem.

I expect you may have an error handler that does not "resume" on completion of handling the error

error handlers are not reentrant, and you cannot enable another error handler while handling an error. which is why you need to resume from an error. Until you "resume" (or end the active procedure) you are still handling the error

 

[DB505050]

I expect you may have an error handler that does not "resume" on completion of handling the error

error handlers are not reentrant, and you cannot enable another error handler while handling an error. which is why you need to resume from an error. Until you "resume" (or end the active procedure) you are still handling the error

I am not quite sure what you mean by 'resume' on completion. Here is my whole routine:

Private Sub cmdOpenP1_Click()
On Error GoTo errhandler
critFieldNum = 1
Call parOpenUpdate(critFieldNum)
Exit Sub
errhandler:
strObjName = Nz(CodeContextObject.Name, "")
Application.VBE.ActiveCodePane.GetSelection merr, nerr, xerr, yerr
strModName = Application.VBE.ActiveCodePane.CodeModule
strProcName = Application.VBE.ActiveCodePane.CodeModule.ProcOfLine(merr, 0)
Call ErrHandlerPublic(strObjName, strModName, strProcName)
Exit Sub
End Sub


Now the error happens within that function parOpenUpdate. Is it significant that the error is happening in a function?

But the thing is, once I open VB Editor, the error handling code works from then on until I close and re-open the database. And I mean even if I close the VB editor it continues to work. I think the key lies here.

 

[DB505050]

This would also explain why it appears to work, when the VBE window is open.

But it also works when the VBE window is closed, after I have opened it at least once. But if I close and re-open the db, I get the same error the first time, until I open and close the VBE again.

To have the error handler refer to the routine in which the error is trapped, the name of the routine can be inserted manually or by the free MZtools

How can it be inserted manually a different way? Will other people with different versions of access have an issue with something from MZtools, or will that code reside wholly inside my application?

Thank you!

 

[DB505050]

I should mention.....I think this is a hopeless endeavor anyway, because I am looking to convert this to an MDE for the end user. I think I am going to abandon the whole idea. I wanted to have this detailed info to streamline error checking if it occurred, but it doesn't look like it is worth the effort.

 

[pr2-eugin]

Hello DB505050, I have to agree with Dave, you do not have a Resume statement.. An Error handler can handle only one error at a time.. If the Err object has not been relinquished of the current error and another error occurs, it does not know what to do.. You should make this changes to the code..

Private Sub cmdOpenP1_Click()
On Error GoTo errhandler
    critFieldNum = 1
    Call parOpenUpdate(critFieldNum)
[COLOR=Blue][B]exitOnErr:[/B][/COLOR]
    Exit Sub
errhandler:
    strObjName = Nz(CodeContextObject.Name, "")
    Application.VBE.ActiveCodePane.GetSelection merr, nerr, xerr, yerr
    strModName = Application.VBE.ActiveCodePane.CodeModule
    strProcName = Application.VBE.ActiveCodePane.CodeModule.ProcOfLi ne(merr, 0)
    Call ErrHandlerPublic(strObjName, strModName, strProcName)
    [COLOR=Blue][B]Resume exitOnErr[/B][/COLOR]
End Sub

The Resume statement here will release the controller, thus if in case another error occurs it would be able to handle that.. Also does the function being called.. i.e parOpenUpdate(critFieldNum) have an Error handler of its own?

 

[mdlueck]

Application.VBE.ActiveCodePane.GetSelection merr, nerr, xerr, yerr

You are aware that this LOC will only execute when the Visual Basic screen is visible?

I stumbled upon Application.VBE in search of some way to detect the name of Modules rather than have to hard code the module name into error handler code which reports where the problem was. I found no way to dynamically detect the name of the module.

I have documented (roughly) my implementation here:

Robust VBA Error Handler
http://www.access-programmers.co.uk/wiki/index.php/Robust_VBA_Error_Handler

 

[gemma-the-husky]

Now the error happens within that function parOpenUpdate. Is it significant that the error is happening in a function?

I would certainly put error handling IN the function paropenupdate, rather than passing it back to the latest active error handler. it may do the same, but it is much cleaner to have each sub working cleanly.

the error 91 is often due to a recordset, or database object not being initiallised.

out of interest, what IS critfieldnum, as it is not dimmed in this block of code?

 

[DB505050]

You are aware that this LOC will only execute when the Visual Basic screen is visible?

That is not exactly the case from what I see. I do have to open VB editor once, but then if I close it, the code works and runs even if it not showing anywhere.

I stumbled upon Application.VBE in search of some way to detect the name of Modules rather than have to hard code the module name into error handler code which reports where the problem was. I found no way to dynamically detect the name of the module.

I have documented (roughly) my implementation here:

Robust VBA Error Handler

Thanks, I will take a look.

 

[DB505050]

The Resume statement here will release the controller, thus if in case another error occurs it would be able to handle that.. Also does the function being called.. i.e parOpenUpdate(critFieldNum) have an Error handler of its own?

Thanks, I will give this a try. I have tried the function both with and without a error handler with no difference.

EDIT: I tried this with no difference. The problem is the VB window has to in some way be open/active for the code to work, as was mentioned.

 

[DB505050]

out of interest, what IS critfieldnum, as it is not dimmed in this block of code?

Just a global variable that has to do with my form. There is one of 6 possible.

 

[Drooten]

Dont make the same mistake I did and thinking that by using these lines of code you get what you want. The 'GetSelection' should be an obvious clue. What this code does is return where you CURSOR is in the code, not the component that is currently running.

Ill keep looking and let you know if I find anything.

Dim xStartLine As Long: Application.VBE.ActiveCodePane.GetSelection xStartLine, 1, 1, 1
Dim strProcName As String: strProcName = Application.VBE.ActiveCodePane.CodeModule.ProcOfLine(xStartLine, 0)

Thanks.

 

[JHB]

What is even more odd: If I set a break point and F8 my way through the code, the error never shows up and the error handling code works perfectly.

Have you tried to set a DoEvents in your code, (to give the system time to finish its work before it continue with your code)?

 

[gemma-the-husky]

I just stumbled on this again, and i know a bit more about this now. I can see two potential issues which might cause your problem.

1. error handling and resume
when you invoke an error handler, your code is processing the error until the error handler is finished (or the sub exits). the error handler finishes by the program explicilty issuing a resume statement.

because error handlers are not re-entrant/recursive - then until you issue a resume statement further errors are not able to be handled by error handlers.

so your problem MAY be that you have not issued a resume statement so the second error gets ignored. (eg, inadvertently you have 'ended' your error handler by using goto label, rather than resume label)

2. manipulating code in VBA.
I see you are making calls to the code pane. if you change code in VBA, your program is immediately reset. Clearly the vba editor itself does not do this, and tools such as MS-Tools do not exhibit this behaviour - so they are implemented in a different way - but it may be whatever you are doing with the code itself is causing the problem.