How can I switch errors back On?

[Chris K]

I understand that Resume signifies where/when the execution process can
continue but does this also switch errors back on? - it's not specifically
mentioned in the help files

 

[Chris K]

Seem to remember using

On Error Off

in the ol days but that doesn't work

 

[Bob Quintal]

Seem to remember using

On Error Off

in the ol days but that doesn't work

From Access 2003 help for the on error statement:

On Error GoTo 0 Disables any enabled error handler in the current
procedure.

 

[Bob Quintal]

Seem to remember using

On Error Off

in the ol days but that doesn't work

From Access 2003 help for the on error statement:

On Error GoTo 0 Disables any enabled error handler in the current
procedure.

 

[David W. Fenton]

I understand that Resume signifies where/when the execution
process can continue but does this also switch errors back on? -
it's not specifically mentioned in the help files

As I answered your other post:

On Error GoTo 0

I would suggest you open the VBE, type "error" into the immediate
window and hit F1. You'll get a list of help topics, and you should
have a read through the On Error Statement help topic.

By the way, I think I sent my previous answer before finishing it --
I'd intended to say something about the VBE options that interact
with your error handling. In A2003, on the GENERAL tab of the VBE
Options dialog, there's an option group for ERROR TRAPPING. I always
set this to BREAK IN CLASS MODULE. This has always seemed
counterintuitive, since BREAK ON ALL ERRORS or BREAK ON UNHANDLED
ERRORS seem like the right choice, but if you do that, it doesn't
work right with class modules (it breaks on the call to the class
module instead of on the error within the class module causing the
error). If you click the HELP button and read the discussion of the
choices, it becomes clear which is the best choic, but I must say
this is a case where the choices only make sense after you've read
the detailed explanation.

 

[Allen Browne]

It works like this:
a) You use On Error GoTo ... to set up an error handler.
b) An error occurs in your code, so control passes to the error handler.
c) The error handler fixes the error and passes control back to the problem
line (Resume) or the next line (Resume Next)
At this point, the error handler you originally set up remains active.

Consequently, if the error recurs (or a following line of the procedure
errors), the error handler will pick it up. This means that if you used
Resume without fixing the error, it falls straight to the error handler
again, and resumes back at the faulty line, so you're in an endless loop. To
avoid this, consider using some kind of variable to count the number of
times the error occurred and bail out rather than loop interminably.

Resume Next (in the error handler) is of limited use -- only if you don't
really care whether the faulting line worked or not.

On Error Resume Next is even less useful, as it makes the code difficult to
debug. You don't even know the error is happening, so you've got little
chance of dealing with it. This is the case not only for the error you may
be thinking of when you write this line, but also for all the other errors
you're not thinking of. The danger is that it masks a multitude of problems.

My personal approach is to always create a separate function to handle
something that could error (e.g. referring to a property that may not
exist.) In other words, I never use On Error Resume Next except in a
function that consists of only 2 or 3 lines.

Hope that's of use.

 

[David W. Fenton]

Resume Next (in the error handler) is of limited use -- only if
you don't really care whether the faulting line worked or not.

Actually, if you have trapped for a specific error that you've
explicitly decided to ignore, that's a perfectly good reason for it.
Almost every case where someone posts code that uses On Error Resume
Next is one which, in my opinion, should be handled with an error
handler with a CASE SELECT that for the specific error number that
is being ignored passes control back to the next line.

This is bad:

On Error Resume Next
DoCmd.OpenReport "rptMyReport"
On Error GoTo 0
[do something else]

Say you're trapping for the NoData error (i.e., the report has no
data, and you've put Cancel = True in the report's OnNoData event)

On Error GoTo errHandler

DoCmd.OpenReport "rptMyReport"
[do something else]

exitRoutine:
Exit Sub

errHandler:
Select Case Err.Number
Case 2501 ' OpenReport cancelled
' ignore it
Resume Next
Case Else
MsgBox Err.Number & ": " & Err.Description, vbExclamation, _
"Error in OpenReport"
Resume exitRoutine
End Select

That's a case in which you specifically want to ignore one
particular error if it happens and continue on to the next line.
This is, in my opinion, the proper way to do it, i.e., using Resume
Next.