Question

I have come across this problem a few times and never been able to resolve it but now I need to solve it once and for all.

I have a procedure which has been throwing runtime errors. This is not a problem as I have an error handler defined at the top of the function and the handler at the bottom something like this:

retryConcat:
On Local Error GoTo concatErr
    'Some Code here
    Exit Sub
concatErr:
    If MsgBox("Could not append the receipt for this transaction to the Receipt viewer logs.", vbExclamation + vbRetryCancel, "Warning - Missing Receipt") = vbRetry Then
        err.Clear
        GoTo retryConcat
    End If

The error handler contains a message box allowing the user to retry if required. Now here is the part which confuses me. The first time an error is thrown it shows the message box and allows the user to retry as expected. The program then jumps to the appropriate line and tries again. However the second time through when the error is thrown it does not jump to the error handler, it jumps out of the procedure and the error handler in the parent catches it instead!

So my question is why does it jump to the parent error handler on subsequent throws. This happens in many places all over my code. In many cases where I can manually check for errors I can stick the code in a while loop to solve it but with runtime errors I am forced to use the error trapping which acts in this rather annoying way.

Any help or advice would be appreciated.

Answer 1

You need ot use Resume retryConcat.

When an error occurs, it jumps into the error handle to concatErr:. You then show the message box, and if the user chooses to retry, the code then jumps to retryConcat. As this you used Goto, it DOES NOT exit the error handler, and so next time the error occurs, it’s already in the error handler and has no choice but to raise the error up the chain to the calling procedure.

Using Resume concatRetry allows it to exit the error handler and resume at the required point, meaning next time the error occurs, it can handle is again.

It probably makes it easier to understand, if you imagine the error handler is a state, not a section of code.