Is there a better error routine way than on error goto statments? These are all I have used pretty much and I was wondering if there in your opinion have been "better" techniques as to go about error routines. I want to see what the different opinions are out there...
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Better error routine then GOTO 4
- Thread starter Jooky68
- Start date
-
1
- #2
Look mom, no GoTo!
On Error Resume next
If err=1234 then DoSomethingWithTheError
If err=4567 then Exit Sub
That's about it!
[/b][/i][/u]*******************************************************
General remarks:
If this post contains any suggestions for the use or distribution of code, components or files of any sort, it is still your responsibility to assure that you have the proper license and distribution rights to do so!
- Thread starter
- #3
-
1
- #4
That is the basic setup that I use. It works well for me.
private sub mySub()
on error goto handler
...some code
exit sub
handler:
...some error handling code
end sub
I also try to avoid as many errors as possible with proper use of data types and checks using functions such as IsNull and IsNumeric.
On occasion I have even used modular boolean flags to allow cetain code to be skiped at certain times to avoid using the error handler. For example when loading a form I will load values into a combo box. But the click event wants to fire so I have a flag set (bolSkipIt) when I am loading the form that will allow me to exit the click event right away (if bolSkipIt then exit sub). When the form load is complete I reset that flag. This may not be the best method but it can avoid errors in the code because items don't yet exist in the combo box.
The on error resume next eliminates the goto but if you have to put error handling code after each possible line that can throw an error and have to deal with each probable error then how is it better?
I am looking forward to an interesting thread. Thanks and Good Luck!
zemp
private sub mySub()
on error goto handler
...some code
exit sub
handler:
...some error handling code
end sub
I also try to avoid as many errors as possible with proper use of data types and checks using functions such as IsNull and IsNumeric.
On occasion I have even used modular boolean flags to allow cetain code to be skiped at certain times to avoid using the error handler. For example when loading a form I will load values into a combo box. But the click event wants to fire so I have a flag set (bolSkipIt) when I am loading the form that will allow me to exit the click event right away (if bolSkipIt then exit sub). When the form load is complete I reset that flag. This may not be the best method but it can avoid errors in the code because items don't yet exist in the combo box.
The on error resume next eliminates the goto but if you have to put error handling code after each possible line that can throw an error and have to deal with each probable error then how is it better?
I am looking forward to an interesting thread. Thanks and Good Luck!
zemp
-
1
- #5
I have been waiting for someone to start a good thread like this...
So here is my take on the situation(s)...
I have always struggled with error nahdling in VB. The previous posts bring back some hidden problems I have run in to. I have played with several ways to make VB handle errors more structured. Inline error trapping is great if you know where the error is going to occur, but what about the situations (real life) where you have now ider what causes an error or more importantly where it occurred. I know VB.Net provides more structured error exception handling but I certainly can't re-write all my apps using .Net.
So my question is...
Does anyone have a good way to make the error handling in VB more structured. i.e. it would be nice to know what module, procedure or function the offending line of code is in or which line that may be.
Let's talk this one up!!
Don
So here is my take on the situation(s)...
I have always struggled with error nahdling in VB. The previous posts bring back some hidden problems I have run in to. I have played with several ways to make VB handle errors more structured. Inline error trapping is great if you know where the error is going to occur, but what about the situations (real life) where you have now ider what causes an error or more importantly where it occurred. I know VB.Net provides more structured error exception handling but I certainly can't re-write all my apps using .Net.
So my question is...
Does anyone have a good way to make the error handling in VB more structured. i.e. it would be nice to know what module, procedure or function the offending line of code is in or which line that may be.
Let's talk this one up!!
Don
I use an self created error messaging function to which I pass the error number, error description, procedure name and title. Then I just pass this information to the function and display with a simple message box.
It is rudamentary, but it has been a god send to at least know which procedure if throwing the error even if I don't know which line of code.
This does require a bit of maintanance because every error handler has to be stet up to call this function.
This line
ErrorMessenger Err.Number, Err.Description, "Form1.MyProcedure", "Error Title"
calls,
Public Sub ErrorMessenger(pNumber As Long, pDesc As String, pProcedure As String, pTitle As String)
'// Procedure to handle all the error messaged that need to be displayed.
MsgBox pNumber & "; " & pDesc & vbCrLf & vbLf & _
"In Procedure: " & pProcedure & ".", , pTitle
End Sub Thanks and Good Luck!
zemp
It is rudamentary, but it has been a god send to at least know which procedure if throwing the error even if I don't know which line of code.
This does require a bit of maintanance because every error handler has to be stet up to call this function.
This line
ErrorMessenger Err.Number, Err.Description, "Form1.MyProcedure", "Error Title"
calls,
Public Sub ErrorMessenger(pNumber As Long, pDesc As String, pProcedure As String, pTitle As String)
'// Procedure to handle all the error messaged that need to be displayed.
MsgBox pNumber & "; " & pDesc & vbCrLf & vbLf & _
"In Procedure: " & pProcedure & ".", , pTitle
End Sub Thanks and Good Luck!
zemp
zemp, that's how I do it also. This gives you also a chance to change the message, or even add your own errors (use a seperate funtion though)
I also pass the VbMsgBoxStyle enum, to receive an answer back in the caller as a VbMsgBoxResult enum:
Dim Ret As VbMsgBoxResult
Ret = ErrorMessenger(Err.Number, Err.Description, "Form1.MyProcedure", "Error Title"
If Ret = vbYes then
'Do This
Else if Ret = vbNo Then
'Do That
Else
'Do Nothing
End If
Public Function ErrorMessenger(pNumber As Long, pDesc As String, pProcedure As String, pTitle As String,Optional ByVal ButtonType As VbMsgBoxStyle) As VbMsgBoxResult
'Error handling here
'This is just something very basic
If Len(pDesc)=0 then
Select Case pNumber
Case 123
pDesc = "myDesciption"
End Select
End If
If ButtonType = vbYesNo Or ButtonType = vbYesNoCancel Then
ErrorMessenger =MsgBox (pNumber & "; " & pDesc & vbCrLf & vbLf & _
"In Procedure: " & pProcedure & ".",ButtonType , pTitle)
End If
End Function [/b][/i][/u]*******************************************************
General remarks:
If this post contains any suggestions for the use or distribution of code, components or files of any sort, it is still your responsibility to assure that you have the proper license and distribution rights to do so!
I also pass the VbMsgBoxStyle enum, to receive an answer back in the caller as a VbMsgBoxResult enum:
Dim Ret As VbMsgBoxResult
Ret = ErrorMessenger(Err.Number, Err.Description, "Form1.MyProcedure", "Error Title"
If Ret = vbYes then
'Do This
Else if Ret = vbNo Then
'Do That
Else
'Do Nothing
End If
Public Function ErrorMessenger(pNumber As Long, pDesc As String, pProcedure As String, pTitle As String,Optional ByVal ButtonType As VbMsgBoxStyle) As VbMsgBoxResult
'Error handling here
'This is just something very basic
If Len(pDesc)=0 then
Select Case pNumber
Case 123
pDesc = "myDesciption"
End Select
End If
If ButtonType = vbYesNo Or ButtonType = vbYesNoCancel Then
ErrorMessenger =MsgBox (pNumber & "; " & pDesc & vbCrLf & vbLf & _
"In Procedure: " & pProcedure & ".",ButtonType , pTitle)
End If
End Function [/b][/i][/u]*******************************************************
General remarks:
If this post contains any suggestions for the use or distribution of code, components or files of any sort, it is still your responsibility to assure that you have the proper license and distribution rights to do so!
zemp,
I use a similar reoutine, however I have thrown in a variable/property that passes the procedure in automatically. THis way I don't have to have an error handling routine in every procedure, just need to set the variable and if an error occurs in a procedure without an error handler, it falls back to the calling procedure until it finds an error handler and the variable is still set to the offending procedure.
What I would LOVE to see is a way to reference the offending code somehow other than a work around - VB's err object includes description and number - you'd think they would have included more info about the offending code - oh well - time to start learning .NET
Don
I use a similar reoutine, however I have thrown in a variable/property that passes the procedure in automatically. THis way I don't have to have an error handling routine in every procedure, just need to set the variable and if an error occurs in a procedure without an error handler, it falls back to the calling procedure until it finds an error handler and the variable is still set to the offending procedure.
What I would LOVE to see is a way to reference the offending code somehow other than a work around - VB's err object includes description and number - you'd think they would have included more info about the offending code - oh well - time to start learning .NET
Don
DonPeters - that variable idea sounds interesting. I am assuming that your variable is then global or at least modular. But wouldn't you have to assign it the procedure name within each procedure? If so then it is still somewhat cumbersome. If not how do you do it.
CCLINT - I like the return value idea. It can give you several options and make the app more user friendly. But to clarify, I only used that messenger function on errors that I had not handled yet, sort of a catch-all. I didn't even think of a response mechanizm because by that point it usally means the app will probably crash. It was just to provide information to me and crash more gracefully.
I will give the return value suggestion a shot. Thanks, a star for you.
Thanks and Good Luck!
zemp
CCLINT - I like the return value idea. It can give you several options and make the app more user friendly. But to clarify, I only used that messenger function on errors that I had not handled yet, sort of a catch-all. I didn't even think of a response mechanizm because by that point it usally means the app will probably crash. It was just to provide information to me and crash more gracefully.
I will give the return value suggestion a shot. Thanks, a star for you.
Thanks and Good Luck!
zemp
zemp - yes you do have to assign it in EVERY procedure - and it is quite cumbersome. If you don't assign it the prodcedure name it becomes useless as I have seen errors reported from the wrong place. I really only use this method when I know I need feedback as to why the error has occured and have only used it a few times - because it's cumbersome. I have seen a few vb add-ins that generate similiar code automatically for you (on vbcode.com and planetsourcecode.com) but can't really get them to work universally.
zemp - found this - it's cool - Saves a lot of work. I modified the code slightly and am planning on modifying it more. I have lots of plans for this...
Happy coding (or in my case erroring)
Don
Happy coding (or in my case erroring)
Don
I once wrote a VB addin, which processes one of the currently opened projects in the IDE. This way you have error handling everywhere you want it, without having to write your handlers by its own. Just make sure you include sections of where you are sure that may raise errors during application use in your own error handlers and have the add in process all functions etc. You can even have an e-mail send to you if you like to, build a function call stack etc. etc. When you build your own tools, you can do all you like to..... But the beauty part is (at least I think) is that you do not have to worry about error handling anymore, this will be done when you are about to compile your code and if you do it right, it will nod smuther your code with handlers so your code stays readable and easy editable.
Have a look at CraigSanders faq222-1694 as well
________________________________________________________________
If you want to get the best response to a question, please check out FAQ222-2244 first
'People who live in windowed environments shouldn't cast pointers.'
________________________________________________________________
If you want to get the best response to a question, please check out FAQ222-2244 first
'People who live in windowed environments shouldn't cast pointers.'
-
1
- #16
Just a quick addendum to the above:
I use a similar technique to trap error messages, but my general routine saves the message to a text file as well as display it to screen. In this way I can often see errors that my users "forgot" to tell me!
I use a similar technique to trap error messages, but my general routine saves the message to a text file as well as display it to screen. In this way I can often see errors that my users "forgot" to tell me!
To place error messages in a file for later reference I like to use the app.logevent. With this you can log all kinds of things and really get a picture of what your app is doing.
But again you have to place code everywhere where you might want to log information. Still cumbersome. Thanks and Good Luck!
zemp
But again you have to place code everywhere where you might want to log information. Still cumbersome. Thanks and Good Luck!
zemp
>, but my general routine saves the message to a text file
simonkue: Good point. I do this also...
zemp: Also a good method! [/b][/i][/u]*******************************************************
General remarks:
If this post contains any suggestions for the use or distribution of code, components or files of any sort, it is still your responsibility to assure that you have the proper license and distribution rights to do so!
- Status
Similar threads
- Locked
- Question
- Locked
- Question
- Locked
- Question