On Error Statement (Visual Basic) 

Since after encountering an error and executing the error code you cannot re-execute the error code within the same application, I provide an elegant way to overcome this, based on Err structure.  Such a case can happen if the error occurs in a loop (e.g. iteratively open files that might not exist). Note that this can be applied in cases you can already spot the 'risky' code.

Suppose you have the following code (standard way of handling errors):

'Loop starts (e.g. For, While, etc)
On Error Go To 100
'Risky line: this may fire an error:
Open filename For Input As #1
'An error is fire, so control is passed to line #100

'Do something - this code should not execute on error condition
...
200: 'continue
....
'Loop ends

Exit Sub ' or Function
100: 'Error code
'Do somethingelse - this code should execute on error condition
Go To 200

The above code will fire the error exception only once, and after that it will raise an unhandled error (e.g. ending the run).
If you want to keep executing the error code subsequently, the following modification is proposed:


On Error Resume Next

'Loop starts (e.g. For, While, etc)
'Risky line: this may fire an error:
Open filename For Input As #1

If Err.number =0 then 'no error was encountered; keep executing code
   'Do something - this code should not execute on error condition
Else
  'Do somethingelse - this code should execute on error condition
  Err.clear
End If
....
200: 'continue: obsolete numbering now, but shown for clarity
'Loop ends

If your code does not assign a value to Err.Number without actually raising an error (as mentioned in previous posts), because ErrObject's ("Err") default property is Err.Number, you can also avoid the error-handling subroutine by testing it this way:

Sub MySub()
    Const ERR_MYERROR As Long = 1001
    On Error Goto ErrHandler

    [procedure code]

    Err.Raise Number:=ERR_MYERROR, Description:="Something weird happened", Source:="VBAProject.MySub()"

ErrHandler:
    If Err <> False Then    'False' Boolean constant = 0
        Select Case Err.Number
            Case ERR_MYERROR
                [...]
            Case Else
                [...]
        End Select
        Err.Clear
    End If
End Sub


Now this is great, but if ERR_MYERROR turns out being, say, a division by zero error you wish to handle in a clean fashion, we can assume there will be other uses for ERR_MYERROR somewhere else in the code. And then the whole Select Case logic will have to be repeated pretty much in every single procedure.

In one VBA project I managed to structure (/centralize) error handling by creating an "AppHandledException" class:

__________________________________________________________________________________________________
Private Type AppHandledExceptionDef
    ErrorObject As ErrObject
    ErrorInfo As String
End Type

Private This As AppHandledExceptionDef

'"This" refers to nothing more than a private local variable of the above defined type,
'that only exists in the instance of the AppHandledException class.
'Use "Me" to refer to the actual instance of the AppHandledException class.

Event OnError(ByRef ExceptionObj As AppHandledException)

Option Explicit
__________________________________________________________________________________________________
'All exposed properties are read-only:

Public Property Get ErrorInfo As String
    ErrorInfo = This.ErrorInfo
End Property
__________________________________________________________________________________________________
'[This] "has-a" [ErrorObject] : expose the properties of This.ErrorObject we're interested in:

Public Property Get ErrorDescription As String
    ErrorDescription = This.ErrorObject.Description
End Property

Public Property Get ErrorNumber As Long
    ErrorNumber = This.ErrorObject.Number
End Property

Public Property Get ErrorSource As Long
    ErrorSource = This.ErrorObject.Source
End Property
__________________________________________________________________________________________________

'Our AppHandledException class now needs a method to raise its event:

Public Sub Throw(ByRef ErrObj As ErrObject, Optional ByVal ErrInfo As String)
'ErrInfo argument is only supplied on "managed" errors.
'ErrObj ErrObject argument is supplied on all errors (VBA run-time and "logical" errors)
    
    'AppHandledException events will throw an instance of the AppHandledException class;
    'Set This.[member] values as per passed parameters:
    
    This.ErrorObject = ErrObj
    If Not IsMissing(ErrInfo) Then This.ErrorInfo = ErrInfo

    RaiseEvent OnError(Me)
    DoEvents
    
    ErrObj.Clear

End Sub

__________________________________________________________________________________________________
'With a little tweaking you could consider using something like this, too:
Public Sub Warn(ByVal WarningMsg As String, Optional ByVal WarningInfo As String)
    
    This.WarningMessage = WarningMsg
    This.WarningInfo = WarningInfo

    RaiseEvent OnWarning(Me)
    DoEvents

End Sub
__________________________________________________________________________________________________
__________________________________________________________________________________________________


Using an instance of the AppHandledException class is quite straightforward: all exposed properties are read-only, which only leaves the "Throw" method to use. For total centralization of error handling, you would instanciate the class, using the WithEvents keyword, in the class module that defines your application object (let's call it clsApplication). Because you cannot use the New keyword along with WithEvents, you'll have to set the object in another statement; the Class_Initialize handler provides perhaps the most logical container for such a statement:


    Public WithEvents AppErrorHandle As AppHandledException
    Option Explicit

    Private Sub Class_Initialize()
        Set AppErrorHandler = New AppHandledException
    End Sub


By declaring an object variable with the WithEvents keyword, the VBA IDE lists AppErrorHandler in the Object drop-down list (the one at the right, at the top of the class' code window), and the object's events in the Procedure drop-down list. Thus you create the event handler for your custom event just as you would for a ButtonClick() event on a form; you'll receive the AppHandledException object thrown by the error-handling subroutine that triggered the call:

    Private Sub AppErrorHandle_OnError(ByRef AppException As AppHandledException)
        [your application-wide error-handling code - log errors with a timestamp, for example]
    End Sub

If you want to capture and reuse your own custom error codes, you'll probably want to use global constants in a standard module... But in a more OOP approach you would create a class (clsAppError) to hold the values (hard-coded or stored in a database) you want to pass to the Err.Raise method - error numbers and descriptions. Another class (clsAppErrors) would instanciate clsAppError as many times as there are errors you want to handle.

Then, event-handling subroutines can be standardized throughout your code: the handler handles both VBA runtime errors and your own app errors:

    'Raise a handled/managed error:
    With MyApp.AppErrors
        Err.Raise Number:=.TestHandledError.Number, _
            Description:=.TestHandledError.Description, _
            Source:=ErrModule & ".MyProcedure(" & argValuesString & ")"
    End With

ErrHandler:
    If Err <> False Then
        MyApp.AppErrorHandle.Throw Err 'if a VBA run-time error occurs, the handler will still pick it up.
    End If


This structure is indeed quite heavy for a simple Excel macro, but for larger-scale Excel add-ins, it could be warranted, as it provides an application-level overhead on all error-handling, definitely beyond the typical Select Case error-handling subroutines scattered throughout the code. And nothing forbids having an AppWarningHandle object featuring a "Warn" method involving a "WarningMessage" property...

E:\2010\IPT\Choo Choo Train\Form1.vb(45): 'picTrain' is already declared as 'Private Dim picTrain() As System.Windows.Forms.PictureBox' in this class.

E:\2010\IPT\Choo Choo Train\Form1.vb(51): 'picTrain' is already declared as 'Friend Dim WithEvents picTrain As System.Windows.Forms.PictureBox' in this class.

can any1 tell me what they mean plz

Although removing the "Exit Sub" before the ErrorHandler label may work in most scenarios, it is not recommended.

Some methods may set Err.Number to a value other than 0 when no error is actually happening.

This is the reason why the error handling routine should only be executed "On Error", but not in normal case.

If you remove the "Exit Sub" before the ErrorHandler label, and your code execute a method that sets Err.Number to a value other than 0 (but doesn't actually raise an exception) just before entering the error handling routine, then your error handling routine will behave as if an exception was thrown when it was not the case!

This is an additional reason to move to structured exception handling using try... catch... finally

To avoid the ErrorHandler block, can't we add the following line after the ErrorHandler label:

ErrorHandler:

If Err.Number <> 0 Then

    Select Case Err.Number

        Case 6 ...

        Case Else

    End Select

End If

I have tried this technique and it works.