VB6 Error Handling Throughout the Program
Solved
Anonymous user
-
Derdonn Posted messages 15 Status Member -
Derdonn Posted messages 15 Status Member -
Hello,
I'll end up making a FAQ by myself.
Here's my question: I'm looking to manage errors in VB6. Of course, I know the On Error Goto ... statement, but what I would like is that no matter which procedure is running, I can go to a specific place. In fact, I don't want to write On Error Goto in each function and then write error handling code, but I want the error management to be global to the whole document. If anyone has a solution (if it exists), please don't hesitate! Thank you!
I'll end up making a FAQ by myself.
Here's my question: I'm looking to manage errors in VB6. Of course, I know the On Error Goto ... statement, but what I would like is that no matter which procedure is running, I can go to a specific place. In fact, I don't want to write On Error Goto in each function and then write error handling code, but I want the error management to be global to the whole document. If anyone has a solution (if it exists), please don't hesitate! Thank you!
8 answers
-
Yes, it's preferable and at the end of the function given the If Err.Number > 0 Then ...
You can retrieve the error number and description like this and pass them as parameters to a public procedure:
Function myFunction() On Error Resume Next 'the code ... If Err.Number > 0 Then Call procErrmsg(Err.Number, Err.Description) Exit Function End If End Function ---------------------------------- Sub procErrmsg(ByVal numErr As Integer, ByVal msgErr As String) MsgBox msgErr, VbExclamation, "Error: " & numErr End Sub
;o)
Polux
--
"What one understands well is clearly stated, And the words to say it come easily."
Nicolas Boileau-
Thank you very much, I'm annoyed to have to paste On Error Resume Next. I may not do it everywhere (for example, not in the code of each button or in the code of each menu). Anyway, your function is very useful to me, and I will save the error in a text file (yes, the error needs to be almost transparent).
One last little question, does Err.number automatically return to 0 when exiting the function?
-
-
"Thank you, I know .NET." (?)
Sorry for misinterpreting your sentence: "Why are errors better managed in .NET???" I understood: Why, in .NET, are errors better managed?
"A Goto gErr sends you directly to gErr: without executing all the code. This can be annoying" -- or it can take on all its interest. And then the resume next positioned after the label gErr: allows you to return in defined cases. A breakpoint after the label allows you to see when an error is detected (during debugging), as soon as it is detected.
"I don't see many differences between a try/catch" -- there is, however! A big one that I know of: with the try catch, there's a system of error propagation in the call stack of functions; errors can be handled at the level you want. I don’t remember super well with .NET either, but I think it does like the others!
"Good evening" -- thank you, likewise. -
Hello
you just need to create a public procedure in a separate module.
then you will just have to call this procedure
--
Chouba,
Riot Pochard .. -
Hello,
Although "On Error Goto..." is allowed in VB, it's not very "clean" or reliable. It's preferable to use "On Error Resume Next" and handle the error by doing:
If Err.Number > 0 Then .... End If.
It's a personal opinion, but from experience, I no longer use "On Error Goto".
;o)
--
“What is well conceived is clearly stated, And the words to say it come easily.”
Nicolas Boileau -
Err.Number returns the error number, there is no need to initialize it. If there is no error, it simply returns 0.
Indeed, it is not necessary to use On Error Resume Next everywhere in the code. It is important to target procedures and functions that may raise an exception.
Good luck for the rest.
;o)
Polux
--
“What is well conceived is clearly said, and the words to say it come easily.”
Nicolas Boileau -
You're welcome, it's my pleasure
Wishing you all the best.
;o)
--
"What is well conceived is clearly stated, And the words to say it come easily."
Nicolas Boileau -
Hello
sorry for the old up,
However:
I checked the date: it would be time to move to .NET :-D, or something that manages errors a little better.
You might ask me:
How did you come across this message if you weren't interested in "VB6 Error handling throughout the program"?, hehe that's exactly what I was looking for unfortunately ^^ ( Office ..., old programs ...)
... Thank you also to you.-
Hi,
Why would errors be better managed in .Net???
You just have to make the effort to want to manage them in VB.
Best wishes.
;o)
--
“What is well conceived is clearly said, And the words to say it come easily.”
Nicolas Boileau- I forgot to mention, in fact, to my memories "on error goto" is more practical (compared to "on error resume next"): "on error resume next" this way does not alert you when an error occurs even during debugging. Here is what I propose for the next ones:
Private Sub mySub()
On Error GoTo gErr
...
gErr:
If Err.Number = 2452 Then 'no parent
Else
Resume Next
End Sub
after cleanliness question... I'm not really Mr. Clean either :-p.
after seeing Polux31's message -->
I see you are very attentive on the forum Polux31, thank you.
for error handling, I agree that we can still do it well, but for me "on error goto/resume" is not worth a try/catch! after maybe it is possible to do this in VB6 (not simple). but even for me .NET > VB6 (not necessarily in all points) without problem, if you have never tried, this is the opportunity plus there are free versions!
hello! - Thank you, I know .NET.
For your information: On Error Resume Next allows you to handle errors in the same way as On Error Goto. Resume Next lets the code run until the error is caught by an If Err.Number <> 0 Then ... for example. A Goto gErr sends you directly to gErr: without executing all the code. This can be inconvenient.
I don't see much difference between a try/catch and an On Error Goto or Resume Next. Nor do I see what makes it better. Both are meant for handling exceptions. The main thing is to make the effort to use them.
Have a good evening
;o)
--
“What is well conceived is clearly stated, And the words to say it come easily.”
Nicolas Boileau
-
-
Because in 2011 there are still people like me struggling to take over VB6 projects and questioning existential matters that a thousand people have already pondered long before. And also because this topic appears at the top of the search engine without fully answering the burning question, I allow myself to add:
YES, it is mandatory to put an "on error" directive AT MINIMUM in the sub main, in the Class_Terminate, and in EACH event handler, otherwise you end up with an executable that crashes at the slightest hiccup.
Source: http://www.vb6.us/tutorials/error-handling "http://www.vb6.us/tutorials/error-handling"
Pollux31's function seems to be the right method to do this by copying and pasting everywhere and ensuring that errors are simply logged into a file without causing further damage. I therefore created a standard module that I include in my projects.
###########GestionErreur.bas###########
'Error handling module v1.0
'Private Sub Command1_Click()
' On Error Resume Next
'
' ...
'
' If Err.Number > 0 Then Call procErrmsg(Err.Number, Err.Description)
'End Sub
Function sur_1_ligne(str As String) As String
sur_1_ligne = Replace(str, vbCrLf, "<CrLf>")
sur_1_ligne = Replace(str, vbCr, "<Cr>")
sur_1_ligne = Replace(str, vbLf, "<Lf>")
End Function
Sub procErrmsg(ByVal numErr As Integer, ByVal msgErr As String)
On Error Resume Next
Open App.Path & "\errors.log" For Append As #1
Print #1, Date & " - " & Time & " - Error " & numErr & ": " & sur_1_ligne(msgErr)
Close #1
End Sub
#################################
