Шаблон для обработки ожидаемых ошибок локально, повторные неожиданные ошибки

Ответ 1

Этот ответ - мое мнение о проблеме, которая, возможно, рассматривается несколько иначе.

При рассмотрении этого блока кода:

On Error Resume Next
personIndex = FindInArray(personName, personArray)
If Err.Number = ERR__ELEMENT_NOT_FOUND_IN_ARRAY Then
    MsgBox "Name not found in person array. Using default person."
Else
End If

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

Ранее упомянутый блок кода будет примерно таким же, как на базовом уровне:

    If Not (in_array(vArray, "Jean-Francois")) Then
        MsgBox "Name not found in person array. Using default person."
    End If

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

Public Function in_array(vArray As Variant, sItem As String) As Boolean

    Dim lCnt As Long

    in_array = False
    Do Until lCnt = UBound(vArray) + 1
        If StrComp(vArray(lCnt), sItem, CompareMethod.Text) = 0 Then
            in_array = True
            Exit Function
        End If
        lCnt = lCnt + 1
    Loop

End Function

Еще лучше было бы использовать функцию in_array() из функции findInArray() и иметь только 1 строку кода в basubub, которая будет:

personIndex = FindInArray(personName, personArray)

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

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

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

Ответ 2

Я создал пользовательский тип, который имеет те же элементы, что и объект Err (число, источник, описание и т.д.). Функция SaveErr будет в основном копировать значения свойств объекта Err в переменную этого типа, а RaiseSavedErr вызовет ошибку, используя эти значения свойств.

Конечно, то же самое можно было бы сделать, используя класс и методы вместо пользовательского типа и функций /subs. Но идея была бы такой же.

Пример:

    On Error Resume Next
    personIndex = FindInArray(personName, personArray)
    savedErr = SaveErr(Err) 'Save values of Number, Source, Description, etc.
    On Error GoTo ErrorHandler
    'Segregate error handling strategies here using savedErr
    If savedErr.Number = ERR__ELEMENT_NOT_FOUND_IN_ARRAY Then
        MsgBox "Name not found in person array. Using default person."
    Else
        RaiseSavedErr savedErr 'rethrows the error
    End If

Я хотел бы знать, есть ли более стандартный или элегантный способ сделать это.

Ответ 3

Вкл. Ошибка Продолжить дальше - корень всего зла в VBA;)

Я не видел весь ваш код, но то, что вы задали в вопросе, может быть легко удовлетворено с помощью MULTIPLE ERROR HANDLERS и RESUME. Это намного проще, чем создание настраиваемого объекта Err и повышение ошибок...

Public Sub sixsixsixBytes()
    On Error GoTo COMMON_ERROR_HANDLER
   'Some code...

    On Error GoTo ARRAY_ERROR_HANDLER
    Call Err.Raise(123)  'lets say error occured in personIndex = ....
    'it will jump to 2nd error handler and come back
    'some code again... 
    'If statement is not required at all
    Call Err.Raise(666)

    On Error GoTo COMMON_ERROR_HANDLER:
    'some code again...
    Call Err.Raise(234)
    Exit Sub

'# MULTIPLE ERROR HANDLERS
COMMON_ERROR_HANDLER:
    Select Case Err.Number
           Case 234: MsgBox 234
           Case 345: MsgBox 345
    End Select

ARRAY_ERROR_HANDLER:
    Select Case Err.Number
           Case 123:
                MsgBox "Name not found in person array. Using default person."
                Resume Next 'or Resume after changing a value (as per your need)
           Case 666:
                MsgBox "Some other error"
                Resume Next
    End Select
End Sub

Ответ 4

Хотя меня немного смущает заданный вопрос (и я читал его довольно много раз к настоящему времени:-)), у меня очень сильное ощущение, что источник этой дилеммы лежит в пределах области действия.
Если все в порядке, я буду использовать некоторые базовые примеры, которые показывают шаблон, но не 1-1 наравне с вашим кодом.

Как отделить ожидаемые ошибки, с которыми я хочу работать локально, от непредвиденных ошибок, с которыми приходится обращаться в процедуре обработки ошибок (или в другом месте)?

Я чувствую, что ответ лежит в самом вопросе.
Обработчики ошибок работают в локальной области подпрограмм/функций, которые вы вызываете из подпрограммы или функции нижнего уровня.

Я нахожу, что если я столкнулся с некоторыми ожидаемыми номерами ошибок локально, я не могут легко "свергнуть" неожиданные номера ошибок, с которыми нужно обращаться в другом месте.

Вы можете, если вы делегируете код, который вы хотите проверить на локальные ошибки, на внешние функции/подпрограммы, которые вы размещаете поверх определенного уровня в call stack. Поскольку они обрабатывают ошибки в пределах их собственного объема, они не будут смешиваться друг с другом.

Рассмотрим этот код:

Sub baseSub()

    Dim n As Integer

    n = checkDivision(1, 0)      
    n = 1 / 0  ' cause an error

End Sub

Public Function checkDivision(iNumerator As Integer, iDenominator As Integer)

    On Error Resume Next
    checkDivision = iNumerator / iDenominator

    If Err.Number <> 0 Then
        checkDivision = Err.Number
        Exit Function
    End If

End Function

Напротив: при применении On Error Resume Next от baseSub все функции, которые помещаются поверх стека вызовов, также игнорируют ошибки. Но это не работает наоборот.

Я думаю, вы можете использовать это в своих интересах.

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

Если это не сработает, тогда у меня нет идей.