Я бы добавил:

• Глобальный объект Err является самым близким к объекту исключения
• Вы можете эффективно "выбросить исключение" с помощью Err.Raise

И просто для удовольствия:

• On Error Resume Next является воплощением дьявола и его следует избегать, поскольку он молча скрывает ошибки.

Итак, вы можете сделать что-то вроде этого

Function Errorthingy(pParam)
On Error GoTo HandleErr

 ' your code here

    ExitHere:
    ' your finally code
    Exit Function

    HandleErr:
        Select Case Err.Number
        ' different error handling here'
        Case Else
            MsgBox "Error " & Err.Number & ": " & Err.Description, vbCritical, "ErrorThingy"
        End Select


   Resume ExitHere

End Function

Если вы хотите испечь пользовательские исключения. (например, те, которые нарушают бизнес-правила) используют приведенный выше пример, но используют goto для изменения потока метода по мере необходимости.

Вот моя стандартная реализация. Мне нравятся ярлыки как самоописательные.

Public Sub DoSomething()

    On Error GoTo Catch ' Try
    ' normal code here

    Exit Sub
Catch:

    'error code: you can get the specific error by checking Err.Number

End Sub

Или с блоком Finally:

Public Sub DoSomething()

    On Error GoTo Catch ' Try

    ' normal code here

    GoTo Finally
Catch:

    'error code

Finally:

    'cleanup code

End Sub

Здесь довольно приличный шаблон.

Для отладки: при возникновении ошибки нажмите Ctrl-Break (или Ctrl-Pause), перетащите маркер перерыва (или что-то еще, что он вызвал) до строки возобновления, нажмите F8, и вы перейдете к строке, "выбросил" ошибку.

ExitHandler - это ваш "Наконец".

Песочные часы будут убиты каждый раз. Текст строки состояния будет очищаться каждый раз.

Public Sub ErrorHandlerExample()
    Dim dbs As DAO.Database
    Dim rst As DAO.Recordset

    On Error GoTo ErrHandler
    Dim varRetVal As Variant

    Set dbs = CurrentDb
    Set rst = dbs.OpenRecordset("SomeTable", dbOpenDynaset, dbSeeChanges + dbFailOnError)

    Call DoCmd.Hourglass(True)

    'Do something with the RecordSet and close it.

    Call DoCmd.Hourglass(False)

ExitHandler:
    Set rst = Nothing
    Set dbs = Nothing
    Exit Sub

ErrHandler:
    Call DoCmd.Hourglass(False)
    Call DoCmd.SetWarnings(True)
    varRetVal = SysCmd(acSysCmdClearStatus)

    Dim errX As DAO.Error
    If Errors.Count > 1 Then
       For Each errX In DAO.Errors
          MsgBox "ODBC Error " & errX.Number & vbCrLf & errX.Description
       Next errX
    Else
        MsgBox "VBA Error " & Err.Number & ": " & vbCrLf & Err.Description & vbCrLf & "In: Form_MainForm", vbCritical
    End If

    Resume ExitHandler
    Resume

End Sub



    Select Case Err.Number
        Case 3326 'This Recordset is not updateable
            'Do something about it. Or not...
        Case Else
            MsgBox "VBA Error " & Err.Number & ": " & vbCrLf & Err.Description & vbCrLf & "In: Form_MainForm", vbCritical
    End Select

Он также ловушки для ошибок DAO и VBA. Вы можете поместить случай выбора в раздел ошибки VBA, если вы хотите ловушку для определенных номеров Err.

Select Case Err.Number
    Case 3326 'This Recordset is not updateable
        'Do something about it. Or not...
    Case Else
        MsgBox "VBA Error " & Err.Number & ": " & vbCrLf & Err.Description & vbCrLf & "In: Form_MainForm", vbCritical
End Select

Professional Excel Development имеет довольно хорошую схему обработки ошибок. Если вы собираетесь проводить время в VBA, это, вероятно, стоит получить книгу. Существует ряд областей, где отсутствует VBA, и в этой книге есть хорошие предложения по управлению этими областями.

PED описывает два метода обработки ошибок. Основная из них - это система, в которой все процедуры точки входа являются подпроцедурами, а все остальные процедуры - это функции, которые возвращают логические значения.

Процедура точки входа используется в операциях Error Error, чтобы фиксировать ошибки в значительной степени, как это было предусмотрено. Процедуры, отличные от точки входа, возвращают True, если ошибок не было и False, если были ошибки. Процедуры, не входящие в точку, также используют On Error.

Оба типа процедур используют центральную процедуру обработки ошибок, чтобы сохранить ошибку в состоянии и зарегистрировать ошибку.

Я использую кусок кода, который я разработал сам, и он хорош для моих кодов:

В начале функции или sub я определяю:

On error Goto ErrorCatcher:

а затем я обрабатываю возможные ошибки

ErrorCatcher:
Select Case Err.Number

Case 0 'exit the code when no error was raised
    On Error GoTo 0
    Exit Function
Case 1 'Error on definition of object
    'do stuff
Case... 'little description here
    'do stuff
Case Else
    Debug.Print "###ERROR"
    Debug.Print "   • Number  :", Err.Number
    Debug.Print "   • Descrip :", Err.Description
    Debug.Print "   • Source  :", Err.Source
    Debug.Print "   • HelpCont:", Err.HelpContext
    Debug.Print "   • LastDLL :", Err.LastDllError
    Stop
    Err.Clear
    Resume
End Select

Также актуальным для обсуждения является относительно неизвестная функция Erl. Если у вас есть числовые метки внутри вашей кодовой процедуры, например,

Sub AAA()
On Error Goto ErrorHandler

1000:
' code
1100:
' more code
1200:
' even more code that causes an error
1300:
' yet more code
9999: ' end of main part of procedure
ErrorHandler:
If Err.Number <> 0 Then
   Debug.Print "Error: " + CStr(Err.Number), Err.Descrption, _
      "Last Successful Line: " + CStr(Erl)
End If   
End Sub 

Функция Erl возвращает самую последнюю встречаемую метку числовой строки. В приведенном выше примере, если после метки 1200: возникает ошибка времени выполнения, но до 1300:, функция Erl возвращает 1200, так как это наиболее удовлетворительно успешно встречающаяся метка строки. Я считаю хорошей практикой поставить метку линии непосредственно над блоком обработки ошибок. Я обычно использую 9999, чтобы указать, что основная часть процесса превзошла его ожидаемое завершение.

ПРИМЕЧАНИЯ:

• Линейные метки ДОЛЖНЫ быть положительными целыми числами - метка типа MadeItHere: не регагонизируется Erl.

• Линейные метки полностью не связаны с фактическими номерами строк VBIDE CodeModule. Вы можете использовать любые положительные числа, которые вы хотите, в любом порядке. В приведенном выше примере имеется только около 25 строк кода, но номера меток строк начинаются с 1000. Нет никакой связи между номерами строк редакторов и номерами меток строк, используемыми с Erl.

• Номера линейных меток не обязательно должны быть в каком-либо определенном порядке, хотя если они не находятся в порядке возрастания, сверху вниз, эффективность и преимущества Erl значительно уменьшаются, но Erl будет сообщать правильный номер.

• Линейные метки относятся к процедуре, в которой они отображаются. Если процедура ProcA вызывает процедуру ProcB и возникает ошибка в ProcB, которая возвращает управление обратно в ProcA, Erl (в ProcA), то возвращается последний номер встречной метки линии в ProcA до он вызывает ProcB. Из ProcA вы не можете получить номера меток строк, которые могут отображаться в ProcB.

Будьте внимательны при установке меток строк в цикле. Например,

For X = 1 To 100
500:
' some code that causes an error
600:
Next X

Если код, следующий за меткой строки 500, но до 600 вызывает ошибку, и эта ошибка возникает на 20-й итерации цикла, Erl возвращает 500, даже если 600 встречается успешно в предыдущих 19 случаях цикла.

Правильное размещение меток строк в процедуре имеет решающее значение для использования функции Erl для получения действительно содержательной информации.

В сети есть какое-то количество бесплатных utilies, которые будут автоматически вставлять числовую метку строки в процедуру, поэтому при разработке и отладке вы получите мелкомасштабную информацию об ошибках, а затем удалите эти метки после того, как код начнет жить.

Если ваш код выводит информацию об ошибках конечному пользователю, если возникает непредвиденная ошибка, при условии, что значение от Erl в этой информации может сделать поиск и исправление проблемы VASTLY проще, чем если не указано значение Erl.

В приведенном ниже коде представлен альтернативный вариант, который гарантирует наличие только одной точки выхода для функции sub/.

sub something()
    on error goto errHandler

    ' start of code
    ....
    ....
    'end of code

    ' 1. not needed but signals to any other developer that looks at this
    ' code that you are skipping over the error handler...
    ' see point 1...
    err.clear

errHandler:
    if err.number <> 0 then
        ' error handling code
    end if
end sub

Остерегайтесь ловушки слонов:

Я не упоминал об этом в этом обсуждении. [Access 2010]

Как ACCESS/VBA обрабатывает ошибки в объектах CLASS, определяется настраиваемой опцией:

Редактор кода VBA > Инструменты > Параметры > Общие > Ловушка ошибок:

Мой личный взгляд на выражение, сделанное ранее в этом потоке:

И просто для удовольствия:

В разделе "Ошибка": "Возобновление ошибок" - это воплощение дьявола, которого следует избегать, поскольку оно скрывает ошибки.

Я использую On Error Resume Next в процедурах, где я не хочу, чтобы ошибка останавливала мою работу и где какой-либо оператор не зависел от результата предыдущих операторов.

Когда я делаю это, я добавляю глобальную переменную debugModeOn, и я устанавливаю ее в True. Затем я использую его следующим образом:

If not debugModeOn Then On Error Resume Next

Когда я доставляю свою работу, я устанавливаю переменную в false, таким образом скрывая ошибки только для пользователя и показывая их во время тестирования.

Также использовать его при выполнении чего-то, что может потерпеть неудачу, как вызов DataBodyRange объекта ListObject, который может быть пустым:

On Error Resume Next
Sheet1.ListObjects(1).DataBodyRange.Delete
On Error Goto 0

Вместо:

If Sheet1.ListObjects(1).ListRows.Count > 0 Then 
    Sheet1.ListObjects(1).DataBodyRange.Delete
End If

Или проверить наличие элемента в коллекции:

On Error Resume Next
Err.Clear
Set auxiliarVar = collection(key)

' Check existence (if you try to retrieve a nonexistant key you get error number 5)
exists = (Err.Number <> 5)