Error Handling inconsistent?

[stranno]

Hi,

please, have a look at this Error Handling method. This seems not to be consistent with the following explanation:

"If your procedure calls another procedure, the On Error Resume Next statement becomes inactive
during the execution of the called procedure. Therefore, you should place an On Error Resume Next
statement in each called procedure that needs one. This is necessary because the Resume Next
behavior applies only to the procedure containing the On Error Resume Next statement. If an
unhandled error occurs in a called procedure, the exception propagates back to the calling procedure,
and execution resumes on the statement following the call. In such cases, the error is not handled."

Or am i wrong?



Sub ErrorHandling()

On Error GoTo ErrHandling 'For non fatale errors which do need to be mentioned

MsgBox 1 / 0
MsgBox "Non Fatale Error 1 handled by ErrHandling"
Call Hulp
MsgBox 1 / 0
MsgBox "Non Fatale Error 2 handled by ErrHandling"
Call Hulp

On Error Resume Next 'For non fatale errors which don't need to be mentioned
MsgBox 1 / 0
MsgBox "This error 3 should/must not be mentioned and is also not handled by ErrHandling or Stoppen"
Call Hulp
On Error GoTo 0
On Error GoTo ErrHandling
Call Hulp

On Error GoTo Stoppen 'For fatale errors which do need to be mentioned after that the process will be stopped
MsgBox 1 / 0
On Error GoTo 0
Call Hulp

MsgBox "This code will not be executed"

On Error GoTo 0
Exit Sub

ErrHandling:
MsgBox "What : " & Err.Description _
& Chr(10) & Chr(13) & "Where : " & "ErrorHandling", vbInformation, "Error: " & Err.Number
Resume Next
Exit Sub

Stoppen:
MsgBox "What : " & Err.Description _
& Chr(10) & Chr(13) & "Where : " & "ErrorHandling" _
& Chr(10) & Chr(13) & Chr(13) & "The process will be stopped", vbCritical, "Error: " & Err.Number
'release objects etc.
End Sub

Sub Hulp()
MsgBox "Hello, this is Hulp"
MsgBox 1 / 0
End Sub

Tip: Use F8 for execution

Regards, Stranno

[SamT]

ErrHandling:
MsgBox "What : " & Err.Description _
& Chr(10) & Chr(13) & "Where : " & "ErrorHandling" & Chr(13) & "Source is: " & Err.Source, vbInformation, "Error: " & Err.Number _

Resume Next
Exit Sub

Stoppen:
MsgBox "What : " & Err.Description _
& Chr(10) & Chr(13) & "Where : " & "ErrorHandling" _
& "Source is: " & Err.Source _
& Chr(10) & Chr(13) & Chr(13) & "The process will be stopped", vbCritical, "Error: " & Err.Number _
& "Source is: " & Err.Source
'release objects etc.
End Sub

Sub Hulp()
Dim X
Static N
N = N + 1
'On Error GoTo Flag
'MsgBox "Generating Div by 0 Error in Hulp"
'X = 1 / 0
MsgBox "Raising Hulp Err # " & N
Err.Raise Number:=vbObjectError + N, Description:="Hulp Err Number " & N, Source:="Hulp"

'MsgBox "Should not see This"
'Flag:
End Sub

[Aflatoon]

What is your actual question? What do you think is inconsistent? (and where is your quoted text from?)

[Jan Karel Pieterse]

Sounds correct to me.

[stranno]

Hi,
The quote comes from
http://msdn.microsoft.com/en-us/library/vstudio/sf1hwa21%28v=vs.100%29.aspx

And as you can see, the on error resume next statement in de main sub (ErrorHandling) is still active in the sub (Hulp) that is been called. And that is not consistent with de quote: "If your procedure calls another procedure, the On Error Resume Next statement becomes inactive during the execution of the called procedure. Therefore, you should place an On Error Resume Next
statement in each called procedure that needs one". Or have i overlooked here something?

What is meant by "becomes inactive during the execution of the called procedure". It doesn't say: in de called procedure, but of the called procedure. What can possibly go wrong in the main sub when the code in de called sub is executed? So, based on the quote, i thought that the on error resume next statement in the main sub is not effective in the sub that is being called from the mainsub right after the on error resume next. But the opposite seems to be true.

Regard,
Stranno

[Aflatoon]

Your called sub is too short for you to see the point. If the on error resume next were still active in the called sub, execution would not jump back out to the calling sub when the error occurs in Hulp.

[SamT]

Your called sub is too short for you to see the point. If the on error resume next were still active in the called sub, execution would not jump back out to the calling sub when the error occurs in Hulp.

He seems to be right. Try this
Sub ErrorHandling()

On Error GoTo ErrHandling
Call Hulp
Exit Sub

ErrHandling:
MsgBox "What : " & Err.Description _
& Chr(10) & Chr(13) & "Where : " & "ErrorHandling", vbInformation, "Error: " & Err.Number
End Sub

Sub Hulp()
Dim X
MsgBox "Hello, this is Hulp"
X = 1 / 0
MsgBox "Still in Hulp. Error Has Occurred"
End Sub

[stranno]

That is true Aflatoon, but one would expect an abortion instead of continuation. Run ErrorHandling2 with and without the on error resume next.
You will notice the difference.


Sub ErrorHandling2()
On Error Resume Next
Call Hulp
End Sub


Sub Hulp()
MsgBox "Hello, this is Hulp"
MsgBox 1 / 0
End Sub

SamT I think you did something comparable.

Regards,
Stranno

[stranno]

SamT, I checked your code and you are right. The line "Still in Hulp. Error Has Occurred" doesn't appear. But on the other hand, the execution from the code in sub Hulp () would have been aborted without the error handling in sub Errorhandling (). Or (again) do i miss something?

Regards,
Stranno

[Jan Karel Pieterse]

If you look at On Error Resume Next as being a sort of rudimentary error handler, the way it works sort of makes sense: an error in the called sub (with no error handling) immediately returns you to the "error handler" in the called sub.

If it is On Error Goto Handler you get sent to the error handler label, if it is Resume Next you get sent to the next statement after the calling statement.

[SamT]

So, the real Error is that MS's explanation is incomplete. Whoodathowt?

[stranno]

Looks like that.

[Jan Karel Pieterse]

On rereading the MSDN page I stumbled on the first two paragraphs:

"
In unstructured exception handling, you place an On Error statement at the beginning of a block of code, and it handles any errors occurring within that block. When an exception is raised in a procedure after the On Error statement executes, the program branches to the line argument specified in the On Error statement. The line argument, which is a line number or line label, indicates the exception handler location.
Sometimes a call is made from the original procedure to another procedure, and an exception occurs in the called procedure. In such cases, if the called procedure does not handle the exception, the exception propagates back to the calling procedure, and execution branches to the line argument."

As far as I can tell (English isn't my native language), this dscribes exactly what goes on in my post #10 in this thread. If you ask me, the article correctly reflects the behavior.

[stranno]

Hi Jan Karel,

Isn't this an article about VB instead of VBA? I am not familiar with unstructured exception error handling. But at least this quote explains the behaviour of the error handling in a called procudure when an error raises there.

Renards,
Stranno

[Jan Karel Pieterse]

AFAIK this was VBA, but it isn't mentioned in the first post, so you might be right.