I was having a problem of screen flickering when running a module. Then decided to used the method Application.Echo
However, I have notice that, using Application.Echo method without Error handling causes my screen to go blank if indeed an error occurs within the module.
As a result, I have thought of two approaches and would like to know which approach would be more efficient and if indeed these are the right ways of dealing with this kind of problem.
Approach 1:
Sub loopThrough()
On Error GoTo ErrorHandler
Me.Requery
Application.Echo False
'A for loop here........
Application.Echo True
exitErr:
Application.Echo True
Exit Sub
ErrorHandler: MsgBox Err.Description
GoTo exitErr
End Sub
Approach 2:
Sub loopThrough()
On Error Resume Next
Me.Requery
Application.Echo False
'A for loop here........
Application.Echo True
End Sub
Never go for approach 2, many things can go wrong here!
Take the following example code:
Sub loopThrough()
On Error Resume Next
Me.Requery
Application.Echo False
'Append new data to table
CurrentDb.Execute "INSERT INTO MyTable SELECT * FROM NewData", dbFailOnError
'Truncate the new data table, this data has been appended
CurrentDb.Execute "DELETE * FROM NewData"
Application.Echo True
End Sub
Say NewData contained an entry that could not fit into MyTable. That operation fails, we continue on, truncate NewData, poof, data gone without a trace.
Did an error occur? Not a clue, because we didn't get notified of an error probably not? Oh, wait, there's missing data! How did that happen?
If you take your first approach here, you:
Get an error message
Don't delete your data if there's an error
Have code that's a tiny bit lengthier
Do remind yourself not to call Application.Echo True twice, that's not necessary.
The usual structure in VBA for proper code is:
Public Sub SomeSub()
On Error GoTo ErrHandler
'Usual code here
ExitHandler:
'Perform operations needed when exiting, e.g. close open connections, set Application.Echo to true
'Then exit:
Exit Sub
ErrHandler:
'Report error here
MsgBox Err.Description
Resume ExitHandler
End Sub
Note that I use the Resume statement. That's specifically intended to jump out of an error handler. As far as I know it has no direct benefits outside of being syntactically clear, but I'm not 100% sure of that.
Related
When I write in VBA for Word or Excel, I typically have an error handler in my main function and call several subs from it, and most of the time, I want subs' messages to get caught in the main function. Typically everything works great with this strategy, and it mimics what I'm used to in C++.
However, I run into trouble when I need a different type of error handling in one or two subs.
For example, when I need to turn on Resume Next for the sake of checking if an object fails and is set to nothing. When I want to turn error handling on, my MainErrorHandler is now out of scope.
Sub Main()
On Error GoTo MainErrorHandler
Application.ScreenUpdating = False
Call OpenFile
Call SubWithOwnErrorHandling
'Do more stuff
GoTo CleanExit
MainErrorHandler:
MsgBox Err.Description
CleanExit:
Application.ScreenUpdating = True
End Sub
Sub OpenFile()
On Error Resume Next
Set objFile = objFSO.OpenTextFile(fileLocation & fileName, 1)
On Error GoTo ErrorHandler ' Label Not Defined!
If objFile Is Nothing Then
Call Err.Raise(2009, , "Out File doesn’t exist.")
End If
End Sub
Likewise, when I want to have a sub handle errors locally and occasionally elevate an error, I'm not sure how exactly to do that.
Sub SubWithOwnErrorHandling()
On Error GoTo SubErrorHandler
isReallyBad = True
If isReallyBad Then
Call Err.Raise(2020, , "Error that needs to cause application to exit!")
Else
Call Err.Raise(2001, , "Error that just needs the function to exit!")
End If
SubErrorHandler:
On Error GoTo MainErrorHandler ' Label Not Defined!
If Err.Number = 2020 Then
Call Err.Raise(2020, , Err.Description)
End If
End Sub
Is there any way to do what I'm trying to accomplish for either case?
Labels are always local.
On Error is always local too - heck, its deprecated ancestor was On Local Error!
So you can't GoTo-jump between procedure scopes (THANK GOD!!)
This means at any given time, there's only ever one of two things the run-time can do On Error:
Jump to a local error handler
Blow up the current stack frame and see if the caller handles it
[ignore the error and happily keep running blindfolded under blue skies and sunshine]
That third point, you guessed it, is what On Error Resume Next does.
One critical error you've done, is specifying an On Error statement inside an error-handling subroutine, and the error-handling subroutine runs regardless of whether you're in an error state or not. That makes following execution extremely confusing, even if that label was legal. Exit Sub or Exit Function (or heck, Exit Property, depending on what's your scope) before the handler, and make sure error-handling code is only ever hit in an error state.
Resetting error handling
So, one thing you want to do, is to reset error handling - here:
On Error Resume Next
Set objFile = objFSO.OpenTextFile(fileLocation & fileName, 1)
On Error GoTo ErrorHandler ' Label Not Defined!
You know objFSO.OpenTextFile can possibly blow up, and you want to handle it yourself, i.e. deal with the objFile Is Nothing possibiilty manually. You can absolutely do that, but then what you need is this:
On Error Resume Next
Set objFile = objFSO.OpenTextFile(fileLocation & fileName, 1)
On Error GoTo 0
On Error GoTo 0 resets error handling, i.e. the next instruction to throw an error will bubble up the call stack, until everything goes up in flames.
Custom Errors
The next thing you want to do, is to raise custom errors.
If isReallyBad Then
Call Err.Raise(2020, , "Error that needs to cause application to exit!")
Else
Call Err.Raise(2001, , "Error that just needs the function to exit!")
End If
That's pretty easy actually - but it's easier with an Enum:
Public Enum AppCustomError
ERR_ReallyBad = vbObjectError + 42
ERR_ReallyReallyBad
ERR_VeryReallyTerriblyBad
ERR_YouGetTheIdea
End Enum
The vbObjectError constant ensures that your custom error numbering doesn't step on toes; your error numbers will all be negative - and with an Enum for each possible error you can throw, you don't need to care what the actual error number is, so you let the enum member mechanics do their thing (e.g. ERR_ReallyReallyBad will be ERR_ReallyBad + 1, automatically).
Then you can do this (assuming you're in a class module - otherwise replace TypeName(Me) with some string literal, or skip it):
On Error GoTo ErrHandler
If isReallyBad Then
Err.Raise ERR_VeryReallyTerriblyBad, TypeName(Me), "Blow up the app!"
Else
Err.Raise ERR_ReallyBad, TypeName(Me), "Blow up this function!"
End If
Exit Sub
ErrHandler:
With Err
Select Case .Number
Case ERR_VeryReallyTerriblyBad
.Raise .Number 'rethrow
Case ERR_ReallyBad
'function blew up, we're done here.
'...
End Select
End With
And then the calling code, which has its own error-handling subroutine, can decide that it can't deal with ERR_VeryReallyTerriblyBad, and just blow everything up by rethrowing:
Exit Sub
MainErrorHandler:
With Err
Select Case .Number
Case ERR_VeryReallyTerriblyBad
.Raise .Number 'rethrow
Case Else
MsgBox .Description
End Select
End With
In a Word I am running a macro which triggers Error dialog sometimes. In PHP there I am used to use #command syntax which causes that in case of error the error is not printed to the output. Is there something similar to prevent the VBA debugger stop working?
My code is
Documents.Add.Content.Paste
and I want to create code, which would test if the result is valid, without breaking the debugger and printing the error, In the case that it failed, I would create timer 1s, and try the command again.
Edit:
Current code:
On Error GoTo ErrHandler
Documents.Add.Content.Paste
If False Then
ErrHandler:
' Add a delay
Dim tmpStart
tmpStart = Timer
Do
DoEvents
Loop While (tmpStart + 1) > Timer
Documents.Add.Content.Paste
End If
Currently error happens at line #11: 4605 - property not available because clipboard is empty or damaged
In your sub-routine or function, insert as the first line:
On Error Resume Next
Or if you want to handle the error:
On Error Goto ErrHandler
If False Then
ErrHandler:
MsgBox Err.Description
Exit Sub ' Or Exit Function
End If
I have a very simple VBA code that should try to open a nonexistent file, send me to an error handler, then back to my code in an infinite loop (intentionally).
However, the compiler only catches the error the first time, then breaks on the second pass.
I have tried every combination of On Error statements to send it back on the second pass, but nothing seems to work.
Here is the code:
Sub TestError()
On Error GoTo errError
lblError:
On Error GoTo errError
'Code that should raise an error and send to errError
Excel.Application.Workbooks.Open ("lakdfjldkj")
Exit Sub
errError:
MsgBox "Code didn't break"
GoTo lblError
End Sub
Is there something I'm missing, or is this a bug?
Don't test this unless you are at peace with having to kill Excel, or add an extra condition for looping
Use Resume to... well... resume processing after the error handler.
Sub TestError()
On Error GoTo errError
'Code that should raise an error and send to errError
Excel.Application.Workbooks.Open "lakdfjldkj"
Exit Sub
errError:
MsgBox "Code didn't break"
Resume
End Sub
I have used code like this to access a certain worksheet, if it is not found then the error handler creates one with the correct name and then resumes the processing.
You need to clear the error message by using:
Err.Clear
Source: https://msdn.microsoft.com/en-us/library/hh2zczch(v=vs.90).aspx
Basically it still thinks you're handling the error, and hasn't reset the handling mechanism, so it doesn't re-trigger until you clear it.
(Resume also clears the Error as well, as you can note by the reference above).
I have tested, it is possible to type :
Resume label1 (line label)
Resume next
Resume 110 (line number)
So I've got a sub (triggered by a command button) which runs a process that seems quite time-consuming (between 5 and 20 seconds, dependant on the machine and how co-operative our network is feeling). To make it clear to the user that stuff is happening that they can't see I change the mouse pointer to an hourglass then change it back when the sub exits, regardless of the reason for the exit.
With that in mind my code looks something like this (illustrative example, not actual code):
Private Sub cmdDoTheThing_Click()
On Error GoTo Err_cmdDoTheThing
Screen.MousePointer = 11 'Hourglass/Equivalent
'Check all data is available to Do The Thing
If Not MyModule.ThingIsDoable(Me.PrimaryKey) Then
MsgBox "Cannot Do The Thing, more preliminary things must be done first."
GoTo Exit_cmdDoTheThing
End If
'Try to Do The Thing (function returns false on failure)
If Not MyModule.DoTheThing(Me.PrimaryKey) Then
MsgBox "Processing of The Thing failed."
GoTo Exit_cmdDoTheThing
End If
'...
'Stuff here I don't want to do if either of the above failed
'...
Exit_cmdDoTheThing:
Screen.MousePointer = 0 'Default mouse pointer
Exit Sub
Err_cmdDoTheThing:
MsgBox "Error " & Err.Number & ": " & Err.Description
Resume Exit_DoTheThing
End Sub
I don't want to repeat Screen.MousePointer = 0 at every possible exit point so I figured a GoTo would serve as a decent shortcut since the Exit_cmdDoTheThing label was needed for error handling anyway.
Is this a valid use-case for a GoTo statement and if not is there some other way I can achieve the same result? I don't want a sudden raptor attack after all.
GoTo can be replaced by using a do-while block (which has a false condition and runs only once) and using 'Exit Do' wherever you want to skip the rest of the code.
So your code might now look like:
Private Sub cmdDoTheThing_Click()
On Error GoTo Err_cmdDoTheThing
Do
Screen.MousePointer = 11 'Hourglass/Equivalent
'Check all data is available to Do The Thing
If Not MyModule.ThingIsDoable(Me.PrimaryKey) Then
MsgBox "Cannot Do The Thing, more preliminary things must be done first."
Exit Do
End If
'Try to Do The Thing (function returns false on failure)
If Not MyModule.DoTheThing(Me.PrimaryKey) Then
MsgBox "Processing of The Thing failed."
Exit Do
End If
'...
'Stuff here I don't want to do if either of the above failed
'...
Loop While FALSE
Exit_cmdDoTheThing:
Screen.MousePointer = 0 'Default mouse pointer
Exit Sub
Err_cmdDoTheThing:
MsgBox "Error " & Err.Number & ": " & Err.Description
Resume Exit_DoTheThing
End Sub
GoTo has to be used with real caution as it may make the code really complex after some iterations in the code. GoTo also allows you to do very weird/ugly things such as jump out of scope without actually going out of scope. With the do-while you ensure the flow of the code while maintaining the sanity and readability of the code.
Raising a custom error can avoid the use of GoTo for subroutines with this error handling structure. This has the added benefit of making it clear to anyone reading the code that failure of certain functions to complete is considered an error in this situation, even if they do not raise an error upon failure.
Public Const cCustomErrNum = 9114
Private Sub cmdDoTheThing_Click()
On Error GoTo Err_cmdDoTheThing
Screen.MousePointer = 11 'Hourglass/Equivalent
'Check all data is available to Do The Thing
If Not MyModule.ThingIsDoable(Me.PrimaryKey) Then
Err.Raise cCustomErrNum,"cmd_DoTheThing_Click()", _
"Cannot Do The Thing, more preliminary things must be done first."
End If
'Try to Do The Thing (function returns false on failure)
If Not MyModule.DoTheThing(Me.PrimaryKey) Then
Err.Raise cCustomErrNum,"cmd_DoTheThing_Click()", _
"Processing of The Thing failed."
End If
'...
'Stuff here I don't want to do if either of the above failed
'...
Exit_cmdDoTheThing:
Screen.MousePointer = 0 'Default mouse pointer
Exit Sub
Err_cmdDoTheThing:
MsgBox "Error " & Err.Number & ": " & Err.Description
Resume Exit_DoTheThing
End Sub
I have writen some code in VBA (Excel) with error handling labels. It worked fine until I recently notice the error handling code gets executed everytime, not just when an error occurs. Does anybody know why this happens? Thanks.
Here's a trivial test case where both msgboxes would pop up.
Sub example()
On Error GoTo err_handle
MsgBox "OK!"
err_handle:
MsgBox "not OK"
End Sub
You want to add an Exit Sub to your routine:
Sub example()
On Error GoTo err_handle
MsgBox "OK!"
Exit Sub
err_handle:
MsgBox "not OK"
End Sub
Look here for a full explaination.
It's because you aren't returning out of the subroutine after the first message box the (OK) one. After that is shown the next line of code is executed which is the "not ok" message.
You could either exit the subroutine early before your error handler label (ExitSub) or goto the end of the subroutine on success (bypassing the "error" routine)
need to add exit sub else the program continues to execute the label as it is the part of the code
Just as a clarification to add some meat to the other answers.
"err_handle:" is only error handling code because you are using it as such. It isn't intrinsically an error handler like a catch block in other languages.
Technically "err_handle:" is just a label that facilitates a goto jump. In your case the goto just happens to be used with an error handler (on error goto)
The generally accepted pattern for error handling is to have an error handler and an exit procedure. A pretty standard code stump might look like this:
Public Function Example() As String
Dim strRtnVal As String 'Return value variable.
On Error GoTo Err_Hnd
'***************************************************************************
'Lock interface code here (hourglass, screenupdating etc.)
'***************************************************************************
'***************************************************************************
'Your code here.
'***************************************************************************
Exit_Proc:
'Prevents "Error Loops" caused by errors within the exit procedure:
On Error Resume Next
'***************************************************************************
'Restore Interface.
'***************************************************************************
Example = strRtnVal 'Set Return Value.
Exit Function
Err_Hnd:
'Display message, do some logging, whatever.
Resume Exit_Proc '<- Run exit procedure.
End Function