Обработка ошибок класса
Класс AXStat содержит программный код, который может инициировать ошибки из кода класса. Если говорить о данном приложении, эти ошибки идентичны ошибкам, которые генерируются Visual Basic, и они могут быть перехвачены. Если, например, пользователь пытается получить доступ к несуществующему элементу (индекс которого больше свойства Count), то класс генерирует ошибку. Класс может обрабатывать ошибку, выдавая соответствующее сообщение, но это не лучший способ обработки ошибок, которые возникают в классах. Разумнее инициировать ошибку и позволить приложению ее обработать.
Для генерирования ошибки исполнения в классе (или в управляющем элементе ActiveX, как это можно увидеть в следующей главе) необходимо воспользоваться методом Raise
объекта Err. Номер ошибки может быть любым целым значением, но следует убедиться в том, что оно не конфликтует с номерами ошибок Visual Basic. Диапазон от 0 до 512 зарезервирован для Visual Basic и не стоит использовать номера из этого диапазона. Можно использовать любой другой номер ошибки, но рекомендуется использовать малые значения и прибавлять к ним константу vbErrorObject. Например, если класс может определять 8 типов ошибок, то можно назначить им номера от 1 до 8 и прибавить к ним константу vbErrorObject.
Если другой элемент управления использует такие же номера ошибок, то можно выяснить, каким элементом управления сгенерирована ошибка, исследуя свойство Source объекта Err. Для выяснения действительного номера ошибки приложение может вычесть эту же константу из значения Err.Number.
Совет
Интересным свойством константы vbErrorObject
является то, что ее значение — очень большое отрицательное число (-2147221504). Таким образом, все номера ошибок, возвращаемые пользовательскими классами, будут отрицательными числами и их очень легко отличить от стандартных ошибок Visual Basic.
Две кнопки с правой стороны тестовой формы генерируют ошибки исполнения, вызывая члены класса AXStat с некорректными аргументами. Следующий программный код показывает, как они вызывают методы Item и Remove с соответствующим кодом, перехватывающим ошибки.
Программа 15.16. Обработка ошибок сгенерированных классом AXStat
Private Sub Command5_Click()
On Error Resume Next
STATS.Remove 9999
If Err.Number <> 0 Then
MsgBox "ERROR # " & Err.Number - vbObjectError _
& vbCrLf & Err.Description & vbCrLf & "In " & Err.Source
' (Ошибка №... в...)
End If
End Sub
Private Sub Command6_Click ()
On Error Resume Next
STATS.Item 9999
If Err.Number <> 0 Then
MsgBox "ERROR #" & Err.Number - vbObjectError _
& vbCrLf & Err.Description & vbCrLf & "In " & Err.Source
' (Ошибка N". . . в. . . )
End If
End Sub
Номер ошибки и ее источник устанавливаются в программном коде класса, методом Raise объекта Err, как показано ранее. Для определения действительного номера ошибки, сгенерированной классом, вычтите константу vbErrorObject
из значения Err.Number. Еще лучше, объявить несколько констант в коде, которые соответствуют значениям ошибок. Ниже приведен перечислимый тип с ошибками, которые генерируются классом AXStats:
Public Enum AXStatErrors
AddError = 1
RemoveError = 2
End Enum
Константы значений ошибок появятся в броузере объектов под классом AXStatsErrors, и их можно использовать в коде приложения в виде выражений AXStatErrors.AddError и AXStatErrors. Remove Error.
Запустите приложение и щелкните на одной из двух кнопок справа на форме. Обе кнопки вызовут ошибку исполнения, пытаясь получить доступ к элементу с индексом 9999. Приложение остановится и выдаст сообщение об ошибке. Почему тестовый проект не перехватил ошибку исполнения с помощью его собственной подпрограммы обработки ошибок?
Ответ прост. По умолчанию Visual Basic в режиме конструирования останавливается в месте возникновения ошибки. Поэтому можно видеть строку, которая вызвала ошибку и исправить соответствующую процедуру в модуле класса. Если создать исполняемый файл и запустить его вне среды разработки, ошибка исполнения будет перехвачена работающим приложением. Можно также изменить поведение механизма перехвата ошибок Visual Basic в процессе конструирования. Откройте меню Tools и выберите команду Options. В диалоговом окне Options, которое появится на экране, выберите вкладку General, как показано на рис. 15.8.
В секции Error Trapping ( Перехват ошибок) вкладки General опция Break in Class Module (Останов в модуле класса) выбрана по умолчанию. Вот почему Visual Basic прерывает выполнение как только возникает ошибка и тестовый проект не имеет шанса обработать ее с помощью собственного обработчика ошибок. Выберите опцию Break on Unhandled Errors (Останов на необработанных ошибках) (как показано на рис. 15.8), закройте диалоговое окно Options и запустите тестовый проект снова. Щелкните кнопку Remove Error или Item Error - на этот раз проект не завершится ошибкой исполнения. Вместо этого появится диалоговое окно с сообщением об ошибке подобное, изображенному на рис. 15.9.
Рис. 15.8. Изменение поведения механизма перехвата ошибок, заданного по умолчанию, во время конструирования.
Рис. 15.9. Перехват ошибок исполнения, генерируемых классом AXStats
