On Error...GoTo 6

[graphix03]

Hi,

Does anyone knows when to code this On Error GoTo code...?
I want to do it right, but I'm confused when/where to
code the error code so when there's an error it knows what to do...so, do you code it in ALL sub routines and functions, or just on certain one? I read a few books, but
they have the error codes just on some procedure for command button, but not all.

any input would be appreciated. thanks much.

 

[CubeE101]

On Error Resume Next
Will ignore ALL errors until
On Error Goto 0
Is met...

though they are ignored, you can still handle them with:
If Err.Number Then

Visit My Site
PROGRAMMER: Red-eyed, mumbling mammal capable of conversing with inanimate objects.

 

[EBGreen]

I think it is a style question. Personally I do it for every sub/function.

[red]"... isn't sanity really just a one trick pony anyway?! I mean, all you get is one trick, rational thinking, but when you are good and crazy, oooh, oooh, oooh, the sky is the limit!" - The Tick[/red]

 

[DrJavaJoe]

The On Error command is placed in the function or sub before the error could arise. Then a Exit Sub or Function statement is used before the error handling code in order to prevent running that code when there is no error. You should use error handling in every sub or procedure where errors may occur.

Private Function DoSomething() As Boolean
On Error GoTo ErrorHandler
'Function Code


Exit Function
ErrorHandler:
'Handle The Error
MsgBox Err.Description, vbExclamation, "Some Error"
End Function


List of Tsunami Relief Donations Sites

Two strings walk into a bar. The first string says to the bartender: 'Bartender, I'll have a beer. u.5n$x5t?*&4ru!2[sACC~ErJ'. The second string says: 'Pardon my friend, he isn't NULL terminated'.

 

[CubeE101]

>>I think it is a style question. Personally I do it for every sub/function.

I agree... Personally I enclose every problem area with ...Resume Next/Goto 0 such as:

On Error Return Next
  CommonDialog1.ShowOpen
  If Err.Number = 0 Then
    Open CommonDialog1.FileName For Input As #1
      text = Input(LOF(1),#1)
    Close
  End If
On Error Goto 0

This Particular style is similar to the Try/Catch functionality in VB.Net...

On Error Goto 0 returns to VB's default error handling, just in case you miss anything...


Visit My Site
PROGRAMMER: Red-eyed, mumbling mammal capable of conversing with inanimate objects.

 

[graphix03]

oh, okay, i understand now. thank you all for your input.
i really appreciate your help.

 

[chiph]

I code mine like this:

Option Explicit

Private Const m_sMODULENAME As String = "My module name"

Private Function Test() As Boolean

    Dim lErrNum As Long
    Dim sErrMsg As String
    Dim vErrParams(5) As Variant

    On Error GoTo Test_ErrHandler
    Test = False  'assume error
    
    '
    ' Insert code here
    '    

    Test = True
    GoTo Test_Cleanup
    
Test_ErrHandler:
    lErrNum = Err.Number
    sErrMsg = Err.Description
    Call CommonErrLogger(m_sMODULENAME, "Test", lErrNum, sErrMsg, _
                    EVENT_TYPE_ERROR, Erl, vErrParams)
    ' Fall through into cleanup

Test_Cleanup:

End Function

The reason why I store the contents of the Err object to local variables is that when you call out to another function within your err handler, they get cleared. And I often need to record error info twice, so I store them for future use. It's also handy in debugging, as I can hover over them to see their value.

I have this set up in MZTools, so all I need to do to add it to a method is a single mouse click.

Chip H.

____________________________________________________________________
Click here to learn Ways to help with Tsunami Relief
If you want to get the best response to a question, please read FAQ222-2244 first

 

[graphix03]

Thanks chiph very much for your input and code. I will try your method too, it seems to be a very good idea.

 

[AndyLee100]

The applications that I work on in my professional capacity use a clever way of handling errors which I have never come across before but it seems to work quite well.

Generally we use a simple string called sErr which is passed by ref through the various functions that are called.

Most of the functions return a boolean whether they have executed correctly or not.

For example:

Public bFunction(r as recordset, sErr as string) as Boolean

On Error goto ErrorHandler

'Database Stuff
If Successful
bFunction = True
Exit Function
End if

Exit Function
ErrorHandler:

sErr = Err.Description etc
bFunction = False
End Function

The calling code will go something like this:

Dim sErr as String
Dim r as Recordset

If Not bFunction(r,sErr) then
Msgbox sErr
Else
'Do something else
End If

If the bFunction returns False then the error is shown in the message box.

This is not particulary useful for the simple example shown here but if you are moving through 20 or so functions then it is invaluable. Most of the functions we use return a boolean. I believe this is because my boss who wrote all the code used to be a C programmer and I understand this is what most of the C functions returned (I have no idea as I have never programmed in C).

Hope you found this helpful.

 

[strongm]

>I have never come across before
>this is what most of the C functions returned

It's similar to a technique that most of the Win32 API uses

 

[AndyLee100]

Chiph,

Just looked at your post. You seem to be doing something similar. I simplified my code for the sake of the post but when we encounter an error a function is called that builds the error string and displays it in a custom message box.

 

[graphix03]

Thanks AndyLee100 for your code. as I can see there are several ways to try to catch errors, so it is helpful and valuable to see them from you all and try them in my application. thanks so much.

 

[dilettante]

This and other fundamentals are better covered by perusing tutorial sites where the time has been taken to spell things out in detail. Look at several to get a balanced perspective, since we all tend to have axes to grind.

For this topic see Error Handling Fundamentals and similar sources.

 

[graphix03]

Thanks much dilettante for the link and your suggestion.
this is a very good link, you're right, i'll have to read it more in much detail. thanks again.

 

[CubeE101]

For this topic see Error Handling Fundamentals and similar sources.

heh, the first 2 topics (Goto 0 & Resume Next) look like what I said above...

LOL... They even used the Common Dialog ShowOpen as an example ;-)

(It's a conspiracy, man)

Visit My Site
PROGRAMMER: Red-eyed, mumbling mammal capable of conversing with inanimate objects.

 

[strongm]

>to spell things out in detail

As an aside, it is a shame that few of them spell out in detail why vbObjectError has the specific value that it does (and, consequently, why you should use it).

 

[AndyLee100]

I have a question.

When I raise an error in a class module using err.raise, how do I get the code using this class to trap the error.

At the moment it generates a run-time error and ends the program execution. It totally ignores the On Error GoTo statement in the code using this class.

 

[strongm]

Check Tools/Options/General and see what Error Trapping is set to

 

[AndyLee100]

Break in Class Module. Changed this to break on unhandled errors and this works ok.

Cheers for that. Basic error I guess.

 

[DrJavaJoe]

Check Tools/Options/General and see what Error Trapping is set to

You can also right click in the code window and in the context menu select Toggle then Break... Very quick and useful when debugging.



Two strings walk into a bar. The first string says to the bartender: 'Bartender, I'll have a beer. u.5n$x5t?*&4ru!2[sACC~ErJ'. The second string says: 'Pardon my friend, he isn't NULL terminated'.