Vb6 on error goto

Оператор On Error (Visual Basic)

Включает подпрограмму обработки ошибок и указывает расположение подпрограммы в процедуре; также можно использовать для отключения подпрограммы обработки ошибок. Оператор On Error используется в неструктурированной обработке ошибок и может использоваться вместо структурированной обработки исключений. Структурированная обработка исключений встроена в .NET, как правило, более эффективна и поэтому рекомендуется при обработке ошибок среды выполнения в приложении.

Без обработки ошибок или обработки исключений любая возникающая ошибка во время выполнения неустранима: отображается сообщение об ошибке и выполнение останавливается.

Ключевое Error слово также используется в инструкции error, которая поддерживается для обеспечения обратной совместимости.

Синтаксис

Компоненты

Комментарии

Мы рекомендуем по возможности использовать структурированную обработку исключений в коде, а не не неструктурированную обработку исключений и инструкцию On Error . Дополнительные сведения см. в разделе Оператор Try. Catch. Finally.

Обработчик ошибок «включен» — это обработчик, который включается оператором On Error . «Активный» обработчик ошибок — это включенный обработчик, который находится в процессе обработки ошибки.

Если ошибка возникает, когда обработчик ошибок активен (между возникновением ошибки и оператором Resume , Exit Sub , Exit Function или Exit Property ), обработчик ошибок текущей процедуры не сможет обработать ошибку. Элемент управления возвращается в вызывающую процедуру.

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

Каждый раз, когда обработчик ошибок передает управление вызывающей процедуре, эта процедура становится текущей процедурой. После обработки ошибки обработчиком ошибок в любой процедуре выполнение возобновляется в текущей процедуре в точке, назначенной оператором Resume .

Подпрограмма обработки ошибок не является процедурой Sub или процедурой Function . Это раздел кода, помеченный меткой строки или номером строки.

Свойство Number

Подпрограммы обработки ошибок используют значение в свойстве Number Err объекта для определения причины ошибки. Подпрограмма должна проверять или сохранять соответствующие значения свойств в объекте Err до возникновения любой другой ошибки или перед вызовом процедуры, которая может вызвать ошибку. Значения свойств в объекте Err отражают только самую последнюю ошибку. Сообщение об ошибке, связанное с Err.Number , содержится в Err.Description .

Оператор Throw

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

Обратите внимание, что On Error GoTo оператор перехватывает все ошибки, независимо от класса исключения.

При следующей ошибке возобновление

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

Конструкция On Error Resume Next может быть предпочтительнее, чем On Error GoTo при обработке ошибок, создаваемых при доступе к другим объектам. Проверка Err после каждого взаимодействия с объектом устраняет неоднозначность относительно того, к какому объекту был доступ из кода. Вы можете быть уверены, какой объект поместил код ошибки в Err.Number , а также какой объект изначально создал ошибку (объект, указанный в Err.Source ).

При ошибке GoTo 0

On Error GoTo 0 отключает обработку ошибок в текущей процедуре. Строка 0 не указывается в качестве начала кода обработки ошибок, даже если процедура содержит строку с нумеровкой 0. On Error GoTo 0 Без оператора обработчик ошибок автоматически отключается при завершении процедуры.

При ошибке goTo -1

On Error GoTo -1 отключает исключение в текущей процедуре. Строка -1 не указывается в качестве начала кода обработки ошибок, даже если процедура содержит строку с нумеровкой -1. On Error GoTo -1 Без оператора исключение автоматически отключается при завершении процедуры.

Чтобы предотвратить выполнение кода обработки ошибок при отсутствии ошибки, поместите инструкцию Exit Sub , Exit Function или Exit Property непосредственно перед подпрограммой обработки ошибок, как показано в следующем фрагменте:

Здесь код обработки ошибок следует за оператором Exit Sub и предшествует оператору End Sub , чтобы отделить его от потока процедуры. Код обработки ошибок можно разместить в любом месте процедуры.

Неисправляемые ошибки

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

При создании объекта, который обращается к другим объектам, следует попытаться обработать все необработанные ошибки, которые они передают обратно. Если вы не можете, сопоставьте коды ошибок в Err.Number с одной из собственных ошибок, а затем передайте их обратно вызывающему объекту. Необходимо указать ошибку, добавив код ошибки в константу VbObjectError . Например, если код ошибки равен 1052, назначьте его следующим образом:

Системные ошибки во время вызовов библиотек динамической компоновки Windows (DLL) не вызывают исключений и не могут быть захвачены с помощью перехвата ошибок Visual Basic. При вызове функций DLL следует проверять каждое возвращаемое значение на успешность или сбой (в соответствии со спецификациями API), а в случае сбоя — значение в Err свойстве LastDLLError объекта .

Источник

On error goto vb6

9. ОБРАБОТКА ОШИБОК

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

При разработке приложений программисты часто встречаются с двумя видами ошибок:

· Физические – ошибки в написании операторов, имен процедур и функций. Команды с такими ошибками никогда не смогу выполниться, поэтому они всегда отслеживаются компилятором уже на этапе разработки приложения.

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

В Visual Basic существуют необходимые команды для управления процедурами обработки логических ошибок (поскольку физические отслеживаются компилятором):

On Error GoTo line

On Error Resume Next

On Error GoTo 0

Команда « On Error GoTo line » при возникновении ошибки передаст управление команде, расположенной на строке с меткой « line ». Команда « On Error Resume Next » передает управление следующему оператору, идущему за оператором, вызвавшем ошибку (простое игнорирование ошибки). Третья команда запрещает (выключает) процедуры обработки ошибок.

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

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

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

• Resume – попытка повторно выполнить команду, вызвавшую ошибку.
• Resume Next – передача управления команде следующей за той, которая вызвала ошибку.
• Resume line – передача управления команде, стоящей на строчке с меткой « line ».

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

Пример использования процедур обработки ошибок приведен в следующем синтаксисе:

On Error GoTo Er1

MyString = “Произошла ошибка, выберете действие”

Er1: MyInt = MsgBox(MyString, vbAbortRetryIgnore,” Ошибка ”)

If MyInt = vbAbort Then Exit Sub

If MyInt = vbRetry Then Resume

If MyInt = vbIgnore Then Resume Next

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

Контрольные вопросы для самопроверки

1. Какие ошибки встречаются в приложениях?
2. Какие команды задают обработку ошибок? Приведите примеры.
3. Как можно обработать возникшую ошибку?
4. В каких случаях, по-вашему, наиболее часто возникают ошибки, которые требуют соответствующей обработки.

Источник

On error goto vb6

Как бы правильно не был бы написан код программы и как бы безошибочно, казалось, программа бы не работала, всегда есть возможность для возникновения непредвиденных ситуаций, когда VB не может выполнить корректно какой-нибудь оператор, что приводит к аварийному завершению программы (фатальный крах). При этом возможна еще и потеря данных, если в это время происходило, например, копирование файла или передача информации. В большинстве своем это ошибки вызваны внешними событиями, например пустой дисковод, когда твоя программа обращается к дискете, отсутствие того файла, который ты пытаешься открыть для, например, чтения, а также ошибки переполнения (когда не хватает памяти для рисунков и ли печати), сетевые сбои, проблемы с буфером обмена и много чего еще. Скажу сразу, что предусмотреть все возможные ситуации практически невозможно, особенно если твоим продуктом будет пользоваться сторонний юзер. Юзера крайне изобретательны. Я не раз сталкивался с возниковением таких ситуаций, спровоцированных юзером, которые у меня, например, в голове не укладываются, и которые потом смоделировать практически невозможно. Видимо по какому-то озарению свыше, юзер может добиться, таких катастрофических результатов, которых я достигнуть при всей внутренней мобилизации сил своего хилого организма не в состоянии. Если поставить перед собой цель создать программу, всегда работающую корректно, можно раздуть код этой программы до безумных размеров и все равно полного успеха не добиться. Microsoft, например, не добился.

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

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

Во-вторых, надо стараться избегать возникновения ошибки программно, тогда ее не придется отслеживать и обрабатывать. Ярким примером такой ситуации может служить программа Scandisk, которую мы рассматривали в прошлой, 10-ой главе. Когда мы тыкали мышью в Dir1 по директориям, все было нормально, при этом выполнялся следующий оператор:
FileName = Dir(OurDir & «*.*», 0) ‘присваиваем переменной значение функции Dir для всех файлов
Если же мы кликали по верхней строке с именем не директории, а диска, возникала ошибка 52 «Неправильное имя файла, или номер». А дело то всего лишь в слеже, который мы поставили в операторе. Дело в том, что функция Dir возвращает имя диска со слежом в конце строки, а имя директории — нет. Если мы его уберем и оператор будет выглядеть так
FileName = Dir(OurDir & «*.*», 0) ‘присваиваем переменной значение функции Dir для всех файлов
вот тогда на диске оператор сработает правильно, зато перестанет читать директории. Можно конечно обработать эту ошибку, о чем мы будем говорить ниже, по ее номеру, но тогда в трех нижних операторах
Attr = GetAttr(OurDir & «/» & FileName) .
той же причиной будет также вызвана ошибка, но с другим номером — 75 «Ошибка доступа пути или файла». Тогда придется обрабатывать и ее. Это тоже вариант. Но по-моему логичнее сразу записать в переменную Ourdir правильный путь при любом раскладе. И надо-то для этого всего лишь убрать слеж из четырех операторов, где возникает ошибка, а в процедуру Dir1_Change добавить проверку, которая добавляет слеж при его отсутствии:
If Right(OurDir, 1) <> «» Then OurDir = OurDir & «» ‘добавленный оператор для устранения ошибки
вот и все дела. Полный исправленный код, если что не понятно, можно скачать здесь.

В-третьих, при обращении к внешним источникам, в том числе к файлам, для получения или вывода информации надо предполагать, что возможно они будут недоступны. Кроме того, надо подумать, какие еще фатальные ситуации могут возникнуть. Вот тут уже надо обрабатывать ошибки конкретно.
Давайте создадим новый exe-проект. По мере необходимости на форму будем класть командные кнопки и в их процедуре отлавливать ошибки. Возьмем пример самой распространенной ошибки — нет того файла, который нам как раз крайне необходим. Положим на форму кнопку Command1 (она будет называться Resume Next) и в ее процедуре напишем операторы открытия файла «aaa.txt» для последовательного чтения.

Private Sub Command1_Click()
Open «aaa.txt» For Input As #1
Close #1
End Sub

Поскольку такого файла никто не создавал, то при запуске программы и нажатии кнопки Command1 возникнет ошибка 53, о чем нам любезно сообщит Windows: «Run-time error ’53’: Файл не найден». Программа аварийно завершится.
Итак, что же нам может предложить VB для предотвращения фатальных ошибок.

Операторы ON ERROR и RESUME (Resume Next).

Перво-наперво, ошибку надо отловить. Сделать это можно с помощью оператора On Error. Однако сам по себе этот оператор работать не будет, это и логично, с отловленной ошибкой ведь надо что-то делать. Самое простой и безбашенный метод (кстати довольно эффективный, когда постоянно возникает ошибка, справиться с ней не можешь и это тебя достало) — присобачить к оператору On Error оператор Resume Next. Тогда получившийся оператор On Error Resume Next в случае возникновения ошибки возвратится в программу и передаст управление оператору, следующему за тем оператором, где возникла ошибка. Однако следует помнить, что On Error Resume Next действует во всей процедуре, и если процедура большая и сложная, то ошибка может возникнуть совсем в другом операторе, нежели ты ожидаешь. Она все равно будет обработана, VB перескочит на следующий оператор, а ты об этом ничего не узнаешь и будешь дня два ломать голову, почему не работает то-то и то-то, хотя все прописано в коде черным по-белому. Ну, тем не менее исправим наш код с использованием оператора On Error:

Private Sub Command1_Click()
On Error Resume Next
Open «aaa.txt» For Input As #1
Close #1
Form1. Print «Процедура кое-как завершена»
Form1. Print «с помощью On Error Resume Next»
Form1. Print «файл не считан, работать не с чем»
End Sub

Текст в операторах Form1.Print написан условно, так как ясно, что он будет выводится независимо от того, есть ошибка или нет. Т.е на самом деле пользователь никакой реальной информации об ошибке не получит и поправить ничего не сможет. Иное дело, если мы к нашему On Error попробуем пристроить оператор безусловного перехода GoTo метка. На самом деле он унаследован от старого Бейсика и использовать его нужно крайне осторожно. Этот оператор отсылает ( в нашем случае, если возникла ошибка) к строке, помеченной меткой, но только внутри текущей процедуры. Положим следующую кнопку Command2 (ее назание GoTo метка) и в ней напишем процедуру

Private Sub Command2_Click()
Dim Msg As String
On Error GoTo ErrorMark
Open «aaa.txt» For Input As #1
Close #1
Exit Sub
ErrorMark:
Msg = «Ой, наверно файл куда-то запропал, попробуйте восстановить!?»
MsgBox Msg, , «Караул, нет данных!»
End Sub

Таким образом, при возникновении ошибки оператор GoTo возвращает нас в программу к строке, помеченной меткой ErrorMark. Под ней пишутся операторы, которые выполняются для реакции программы (или юзера) на ошибку. Обратите внимание, чтобы они не выполнялись в случае, когда ошибки нет, перед меткой поставлен оператор Exit Sub, который прерывает выполнение процедуры, не дожидаясь оператора End Sub. В качестве реакции на ошибку у нас выводится MessageBox с советом для юзера. Обратите снова Ваше драгоценное внимание на то, что в сообщении я употребил слово «наверное». Реально при открытии файла могут возникать разные ошибки и я лишь только предполагаю, что у нас ошибка 53.
Как я говорил выше, в сложных и больших процедурах, чтобы не отлавливать ошибки в других операторах оператор GoTo метка. надо выключить. Для этого, после сомнительного оператора, могущего вызвать ошибку, надо вставить строку
On Error GoTo 0
Тогда обработчик ошибок прекратит свою работу и ошибки в последующих операторах отслеживаться не будут.
Если в подпрограмме обработки ошибок имеется возможность устранить причину ее возникновения, то надо вернуться на тот же оператор и снова его выполнить, уже без ошибки. Для этого подпрограмму обработки ошибок заканчивают оператором Resume. Если же надо перейти к другой строке, помеченной меткой, то программу обработки ошибок надо закончить оператором Resume метка. Ну а теперь перейдем к самому интересному — анализу ошибок.

Объект Err.
Вот как раз с помощью этого объекта мы можем проанализировать, какая ошибка произошла, т.е. по сути, получить ее номер, и в зависимости от ситуации программно решить вопрос об ее устранении или наоборот, заставить юзера производить какие-либо судоржные действия.
Основным свойством объекта Err является свойство .Number, которое и возвращает нам номер ошибки. Настолько основным, что .Number можно не писать. Синтаксис будет такой:
Переменная=Err.Number или Переменная=Err
Это свойство для нас главное. Кроме того (для сведения) имеются еще такие свойства:
.Sourse — имя текущего проекта VB
. Description — cтрока, соответствующая строке, возвращаемой функцией Error для кода ошибки, указанного в свойстве Number, если такая строка существует
.HelpFile — полное имя (включая диск и путь) файла справки Visual Basic.
. HelpContext — контекстный идентификатор файла справки Visual Basic, соответствующий ошибке с кодом, указанным в свойстве Number.
. LastDLLError — содержит системный код ошибки для последнего вызова DLL (только для 32-разрядных Microsoft Windows)

Положим на форму Text1 со свойством Multiline — True, кнопку Command3 (название — Прочитать файл), а также для того, чтоб нам было удобно создавать, убивать файл, положим еще три кнопки Command4, Command5 и Command6, называющиеся соответственно «Создать aaa.txt», «Создать пустой aaa.txt» и «Убить aaa.txt». В процедурах этих трех кнопок напишем:
код для создания файла путем открытия и записи туда слов «не пустой» в Command4

Private Sub Command4_Click()
‘создать aaa.txt
On Error Resume Next
Kill (App.Path & «aaa.txt»)
Open App.Path & «aaa.txt» For Output As #1
Print #1, «не пустой»
Close #1
Text1.Text = «Создан не пустой файл aaa.txt»
End Sub

в Command5 создадим пустой файл, т.е. файл не содержащий ни одного символа

Private Sub Command5_Click()
‘создать пустой aaa.txt
On Error Resume Next
Kill (App.Path & «aaa.txt»)
Open App.Path & «aaa.txt» For Output As #1
Close #1
Text1.Text = «Создан пустой файл aaa.txt»
End Sub

и в Command6 — программу для уничтожения файла

Private Sub Command6_Click()
‘убить aaa.txt
On Error Resume Next
Kill (App.Path & «aaa.txt»)
Text1.Text = «Убит файл aaa.txt»
End Sub

Обратите внимание, что перед созданием файла, я убиваю старый. Так как старый файл может на тот момент не существовать (в этом случае возникнет ошибка), я использую On Error Resume Next.
Теперь создадим коротенькую процедуру загрузки формы для проверки в самом начале, существует ли файл aaa.txt

Private Sub Form_Load()
Text1.Text = «»
If Dir(App.Path & «aaa.txt») = «» Then Text1.Text = «Файла aaa.txt не существует»
End Sub

А вот теперь в кнопке Command3 напишем полноразмерный обработчик ошибок.

Private Sub Command3_Click()
‘объявляем переменную для считывания данных из файл а
Dim Stroka As String
‘использование объекта Err при обработке ошибок
On Error GoTo ErrorMark
ForOpen:
Open App.Path & «aaa.txt» For Input As #1
Line Inpu t #1, Stroka
Text1.Text = Text1.Text & «Файл успешно открыт, содержание файла: » & Stroka & vbCrLf
Close #1
Exit Sub
ErrorMark:
Close #1
‘выводим возможные данные об ошибке
Text1.Text = «Возникла ошибка # » & Err.Number & vbCrLf
Text1.Text = Text1.Text & Err.Description & vbCrLf
Text1.Text = Text1.Text & «В » & Err.Source & vbCrLf
Text1.Text = Text1.Text & «Полный путь хелпа » & Err.HelpFile & vbCrLf
Text1.Text = Text1.Text & «Идентификатор файла спраки VB » & Err.HelpContext & vbCrLf
Text1.Text = Text1.Text & «DLL » & Err.LastDllError & vbCrLf
‘Ecли файла нет, то создем его
If Err = 53 Then
Open App.Path & «aaa.txt» For Output A s #1
Print #1, » »
Close #1
Text1.Text = Text1.Text & «Создан новый файл aaa.txt» & vbCrLf
‘возвращаемся на исходную позицию
Resume ForOpen
‘если файл пустой дописываем в него пробел
ElseIf Err = 62 Then
Open App.Path & «aaa.txt» For Append As #1
Print #1, » »
Close #1
Text1.Text = Text1.Text & «Ошибка файла aaa.txt исправлена » & vbCrLf
‘возвращаемся на исходную позицию
Resume ForOpen
Else
Text1.Text = Text1.Text & «Не знаю, что делать с ошибкой, файл не открыт »
End If
End Sub

Теперь, если мы убъем файл кнопкой «Убить aaa.txt» и нажмем кнопку «Прочитать файл», то в Text1 выведется вся доступная информация об ошибке, создастся новый файл и процедура начнет выполнятся по-новой уже с существующим файлом. Аналогичная ситуация возникает при создании пустого файла. При чтении такого файла возникает ошибка 62 — чтение после конца файла. Мы также получаем информацию об ошибке, дописываем в файл пробел и по Resume вновь запускаем процедуру. Если возникает ошибка с номером, который мы не знаем, то просто выводим об этом сообщения в Text1.

Замечу, что с операторами Open и Close надо обращаться аккуратно. Все файлы должны своевременно открываться и закрываться. Если путаешься с работой с файлами, посмотри Главу 7. Скачать исходник можешь вверху страницы.

Резюме:
Таким образом, обработка ошибки включает в себя:
— Обнаружение ошибки On Error.
— Переход на подпрограмму обработки GoTo (или, на крайняк, на следующий оператор с помощью Resume Next).
— Определение ошибки Err.Number и в зависимости от этого выполнение каких-то действий.
— Возврат Resume после устранения ошибки на оператор, вызвавший ошибку.

Для очистки совести скажу еще про функцию Error. Она по номеру ошибки выводит пояснение — что это за ошибка. Синтаксис:
Строковая переменная=Error(номер ошибки)
Если хотите, положите на форму последнюю кнопку Command7 и для вывода пояснений к ошибкам, например с 52 по 62 напишите такой код и посмотрите, что получится.

Private Sub Command7_Click()
Dim ErrorNumber As Long
Text1.Text = «»
For ErrorNumber = 52 To 64
Text1.Text = Text1.Text & Error(ErrorNumber) & vbCrLf
Next ErrorNumber
End Sub

Совершенно ничего сложного. Ну-с с этим все.

Источник

Код (vb.net):

Код (vb.net):

Отфильтровать:

Showing 1 to 87 of 87 entries

Последнее редактирование: 26 авг 2015

Активизирует подпрограмму обработки ошибок и указывает положение подпрограммы в процедуре; используется также для отключения подпрограммы обработки ошибок.

• On Error GoTo строка — Активизирует подпрограмму обработки ошибок, начало которой определяется обязательным аргументом строка, значением которого может быть любая метка строки или номер строки. Если возвращается ошибка выполнения, управление передается на указанную строку и запускается обработчик ошибок. Аргумент строка должен определять строку в той же процедуре, в которой находится инструкция On Error; в противном случае возникает ошибка компиляции.
• On Error Resume Next — Указывает, что возникновение ошибки выполнения приводит к передаче управления на инструкцию, непосредственно следующую за инструкцией, при выполнении которой возникла ошибка. Рекомендуется при доступе к объектам использовать эту форму инструкции, а не On Error GoTo.
• On Error GoTo 0 — Отключает любой активизированный обработчик ошибок в текущей процедуре.

Замечания

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

«Включенным» обработчиком ошибок называют подпрограмму, которая указана в инструкции On Error; «активным» обработчиком ошибок является включенный обработчик ошибок, который обрабатывает текущую ошибку. Если ошибка возникает в самом обработчике ошибок (в промежутке между возникновением ошибки и выполнением инструкции Resume, Exit Sub, Exit Function или Exit Property), то обработчик ошибок, определенный в текущей процедуре, не может обработать ошибку. Управление в этом случае возвращается в вызывающую процедуру; если в вызывающей процедуре включен обработчик ошибок, то обработка ошибки передается ему. Если этот обработчик ошибок является в данный момент активным, т.е. уже обрабатывает ошибку, то управление снова передается назад в вызывающую процедуру и т.д. до тех пор, пока не будет найден включенный, но не активный обработчик ошибок. Если включенный, но неактивный обработчик ошибок найден не будет, ошибка становится фатальной в том месте программы, в котором она впервые возникла. При каждой передаче управления обработчиком ошибок в вызывающую процедуру эта процедура становится текущей. После завершения обработки ошибки обработчиком в любой процедуре возобновляется выполнение текущей процедуры с той ее части, которая указана в инструкции Resume.

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

Для определения причины ошибки в подпрограммах обработки ошибок используют значение свойства Number объекта Err. Необходимо обеспечить в подпрограммах обработки ошибок проверку или сохранение существенных значений свойств объекта Err перед тем, как может возникнуть новая ошибка или перед вызовом процедуры, в которой может возникнуть новая ошибка. Значения свойств объекта Err описывают последнюю ошибку. Текст сообщения об ошибке, соответствующего коду ошибки Err.Number содержится в свойстве Err.Description.

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

При обработке ошибок, возникающих при доступе к другим объектам, рекомендуется использовать конструкцию On Error Resume Next, а не конструкцию On Error GoTo. Проверка объекта Err после каждого взаимодействия с другим объектом позволяет устранить неопределенность в том, при доступе к какому объекту возникла ошибка. Это позволяет всегда точно знать, какой объект поместил значение кода ошибки в свойство Err.Number, а также в каком объекте возникла ошибка (эта информация содержится в свойстве Err.Source).

Конструкция On Error GoTo 0 отключает обработку ошибок в текущей процедуре. Эта конструкция не задает переход на строку 0 для обработки ошибок, даже если в процедуре имеется строка с номером 0. Если инструкция On Error GoTo 0 не выполнялась, то обработчик автоматически отключается при выходе из процедуры.

Для того, чтобы предотвратить выполнение программы обработки ошибок в тех случаях, когда ошибка не возникла, следует помещать соответствующую инструкцию Exit Sub, Exit Function или Exit Property сразу после подпрограммы обработки ошибки, как в следующем примере:

Sub InitializeMatrix(Var1, Var2, Var3, Var4)
	On Error GoTo ОбработкаОшибок
	. . .
	Exit Sub
ОбработкаОшибок:
	. . .
	Resume Next
End Sub

В этом примере программа обработки ошибок помещена между инструкциями Exit Sub и End Sub, что позволяет отделить ее от части программы, соответствующей нормальному выполнению процедуры. Программу обработки ошибок можно разместить в любом месте процедуры.

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

Err.Number = vbObjectError + 1052

Системные ошибки при вызовах библиотек динамической компоновки (DLL) не приводят к возникновению исключений и не перехватываются средствами Visual Basic. При вызове функций из библиотек DLL необходимо проверять, успешно ли возвращается каждое значение (согласно спецификациям API), и в случае неудачи проверять значение свойства LastDLLError объекта Err.

Пример

В начале этой программы инструкция On Error GoTo определяет положение подпрограммы обработки ошибок в процедуре. В данном примере попытка удалить открытый файл приводит к возникновению ошибки с кодом 55. Ошибка обрабатывается в подпрограмме, после чего управление возвращается инструкции, которая привела к возникновению ошибки. Инструкция On Error GoTo 0 отключает перехват ошибок. После этого инструкция On Error Resume Next задает отложенный перехват ошибок, что позволяет точно определить, в каком контексте возникла ошибка, генерируемая в следующей инструкции. Следует отметить, что после обработки ошибки вызывается метод Err.Clear для сброса значений свойств объекта Err.

Sub OnErrorStatementDemo()
	On Error GoTo ErrorHandler			' Включаем программу обработки 
						' ошибок.
	Open "TESTFILE" For Output As #1		' Открываем файл.
	Kill "TESTFILE"				' Попытка удалить открытый 
						' файл.
	On Error Goto 0				' Отключаем перехват ошибок.
	On Error Resume Next			' Откладываем перехват ошибок.
	ObjectRef = GetObject("MyWord.Basic")	' Запускаем несуществующий 
						' объект, а затем проверяем 
						' ошибку механизма управления 
						' программируемыми объектами.
	If Err.Number = 440 Or Err.Number = 432 Then
	' Выводим сообщение для пользователя и очищаем объект Err.
		Msg = "Ошибка при попытке открыть программируемый объект!"
		MsgBox Msg, , "Проверка отложенной ошибки"
		Err.Clear			' Очищаем поля объекта Err.
	End If	
Exit Sub					' Выходим из процедуры, чтобы
						' не попасть в обработчик.
ErrorHandler:					' Обработчик ошибок.
	Select Case Err.Number			' Определяем код ошибки.

Case 55						' "Ошибка "Файл уже открыт".
			Close #1		' Закрываем открытый файл.
		Case Else
	' Здесь размещаются инструкции для обработки других ошибок... 
	End Select
	Resume					' Возобновляем выполнение
						' со строки, вызвавшей ошибку.
End Sub

Despite your best efforts to cover all possible contingencies, run-time errors will occur
in your applications. You can and should do all you can to prevent them, but when they happen
you have to handle them.

• Introduction
• Trapping Errors at Run-Time
• Building Error Handlers
• Raising Your Own Errors

• Summary

Introduction

The various functions, statements, properties and methods available in Visual Basic and
the components used in Visual Basic expect to deal with certain types of data and behavior
in your applications. For example, the CDate() function can convert a value to a Date variable.
The function is remarkably flexible in the type of information it can accept, but it expects
to receive data that it can use to derive a date. If you provide input that it can’t convert, it
raises error number 13 — «Type mismatch» — essentially saying «I can’t handle this input data.»

In an application, this type of error may be a program logic error (you simply passed the wrong
data) or it may be a data entry error on the part of the user (you asked for a date and the user
typed a name). In the first case, you need to debug the program to fix the mistake. However,
there is no way for you to anticipate the behavior of the end users of the application. If the
user enters data you can’t handle, you need to deal with the situation.

Dealing with errors at run-time is a two step process:

1. Trap the Error
   
   Before you can deal with an error, you need to know about it. You use VB’s
   On Error statement to setup an error trap.

2. Handle the Error
   
   Code in your error handler may correct an error, ignore it, inform the
   user of the problem, or deal with it in some other way. You can examine
   the properties of the Err object to determine the nature of the error.
   Once the error has been dealt with, you use the Resume statement to
   return control to the regular flow of the code in the application.

In addition to dealing with run-time errors, you may at times want to generate them.
This is often done in class modules built as components of ActiveX server DLLs or EXEs.
It is considered good programming practice to separate the user interface from the
program logic as much as possible, so if a server component cannot deal with an error,
it should raise the error in its client application rather than simply display an error
message for the user.

In VB5, there is an option that allows you to specify that an application
has been designed for unattended execution (this is typically used for
remote server applications). If you plan to allow the application to run
unattended or on a remote computer, you can’t simply display an error message
because there will be nobody there to see it or dismiss the message box.

Trapping Errors at Run-Time

Before you can do anything to deal with a run-time error, you need to capture the
error. You use the On Error statement to enable an error trap. On Error will
redirect the execution in the event of a run-time error. There are several
forms of the On Error statement:

• On Error Goto label
  
  This form of the On Error statement redirects program execution to the
  line label specified. When you use this form of On Error, a block of
  error handling code is constructed following the label.
• On Error Resume Next
  
  This form of the On Error statement tells VB to continue with the line
  of code following the line where the error occurred. With this type of
  error trap, you would normally test for an error at selected points in
  the program code where you anticipate that an error may occur.
• On Error Goto 0
  
  On Error Goto 0 disables any error handler within the current procedure.
  A run-time error that occurs when no error handler is enabled or after
  an On Error Goto 0 is encountered will be handled using VB’s default
  error handling logic.

It’s not necessary to code an error handling routine in every procedure you
write in Visual Basic. If an error is raised in a procedure, VB will work its
way back up through the call tree looking for an error handler.

Public Sub SubA()
On Error Goto ProcError

  ' other code
  MsgBox FuncA()

ProcExit:
  Exit Sub

ProcError:
  MsgBox Err.Description
  Resume ProcExit

End Sub
Private Function FuncA() As Date

  FuncA = CDate("hi there")

End Function

In this example, procedure SubA enables an error handler using the statement
On Error Goto ProcError. When function FuncA is called in the MsgBox statement,
the On Error Goto ProcError handler is still enabled. The CDate function in FuncA
will generate error 13 (type mismatch) because CDate can’t make a date from the
input data. VB first looks in FuncA for an error handler. None was enabled, so
the error is propogated back up the call tree to SubA. Since there is an error
handler in SubA, program execution is redirected to the ProcError label in SubA.
The MsgBox statement displays a description of the error and the Resume statement
directs VB to continue execution at the ProcExit label.

There are some situations where VB cannot pass an error back up the call tree.
This applies to Sub Main, most event procedures, and the Class_Terminate
event procedure. Sub Main (if defined in the project property sheet) is the
first code executed, so there is no procedure higher in the tree at application
startup time. Most event procedures are also fired by Visual Basic when no
other code is running so these are also at the top of the tree. Finally,
the Class_Terminate event of class modules cannot raise an error because
this event can also occur when no other code is executing in the application.

If an error is generated in one of these types of procedures and no error handler
is enabled in the procedure, VB invokes its own default error handler, displays
a message, and terminates the application. Because of this behavior, it is vital
that you always code an error handler in Sub Main, all event procedures, and the
Class_Terminate event for class modules.

Unlike the Class_Terminate event, the Class_Initialize event of a
class module can raise an error or allow it to go untrapped.
However, it is considered good programming practice to have
classes trap their own errors, deal with them if possible, and
if necessary raise errors explicitly, providing a number and
description defined within the class.

You can code your classes to map any error the class encounters
to class-defined error numbers, but given the large number of
potential errors that could occur in an application, that may
not always be practical. An alternative is to have the class
assign specific numbers and descriptions to errors that are
specific to problems with the code or data in the class (such
as a value that violates a rule for the data) but pass out
standard VB errors (such as error 13 — type mismatch) as is.
This allows applications using the class to explicitly handle
the errors exclusive to the class with customized code, but
handle standard VB errors with more generic code.

Regardless of the approach you take, you must always ensure that
private data within the class is valid and that code within
the class cleans up any local or module level object variables
it creates. This may require you to setup an error handler that
traps errors, cleans up local object variables, and then raises
the same error again.

Building Error Handlers

Trapping an error using the On Error statement is only the first step in dealing with run-time
errors in your code. You must also deal with the error in some way, even if the error handling
code is as simple as ignoring the error (a perfectly valid approach in some situations) or
displaying a message for the user.

The first step in handling an error is determining the nature of the error. This is accomplished
by examining the properties of Visual Basic’s Err object. The Err object includes the following
properties:

• Number
  
  This is the error number that was raised.
• Description
  

  This contains a descriptive message about the error. Depending on the error, the
  description may or may not be useful. (Microsoft Access, for example, has the
  the infamous error message «There is no message for this error.»)

• Source
  
  The Source property tells you what object generated the error.
• HelpContext
  
  If a help file has been defined for the component that raised the error, this
  property will give you the help context ID. You can use this property along
  with the HelpFile property to display context sensitive help
  for errors in your application or as a debugging aid.
• HelpFile
  
  This is the name of the help file that contains additional information about
  the error (if a help file has been provided).

It is important that you rely only on the error number to determine the nature of
the error. While the Description and other properties may contain useful information,
only the Number property is a reliable indicator of the exact error that occurred.

A common approach in coding an error handler is to build a Select Case block
based on the Number property of the Err object:

Public Sub SubA()
On Error Goto ProcError

  ' code that raises an error

ProcExit:
  Exit Sub

ProcError:
  Select Case Err.Number
    Case X
      ' handle X
    Case Y
      ' handle Y
    Case Z
      ' handle Z
    Case Else
      ' default
      MsgBox Err.Description
      Resume ProcExit
  End Select

End Sub

X, Y, and Z may be literal numbers (Case 13 ‘ type mismatch) or, if they are available,
symbolic constants representing the numbers.

If you are building a class module that will raise class-defined errors, you should
provide a public enumeration in the class that defines constants for any errors
raised by the class. By providing constants, code that creates objects defined by
the class can use the constants instead of the literal numbers and protect itself
from changes in the actual numbers.

Once you have trapped and handled the error, you need to tell Visual Basic where to
continue with program execution. There are several options available when an error
handling block is entered using On Error Goto label:

• Resume
  
  The Resume statement tells VB to continue execution with the
  line that generated the error.
• Resume Next
  
  Resume Next instructs Visual Basic to continue execution with the line following
  the line that generated the error. This allows you to skip the offending code.
• Resume label
  
  This allows you to redirect execution to any label within the current procedure.
  The label may be a location that contains special code to handle the error,
  an exit point that performs clean up operations, or any other point you choose.
• Exit
  
  You can use Exit Sub, Exit Function, or Exit Property to break out of the current
  procedure and continue execution at whatever point you were at when the procedure
  was called.
• End
  
  This is not recommended, but you can use the End statement to immediately
  terminate your application. Remember that if you use End, your application is
  forcibly terminated. No Unload, QueryUnload, or Terminate event procedures
  will be fired. This is the coding equivalent of a gunshot to the head for
  your application.

In addition to these statements, you can also call the Clear method of the Err object
to clear the current error. This is most often used with inline error handling, as shown
below:

Public Sub CreateFile(sFilename As String)

  On Error Resume Next
  ' the next line will raise an error if the file 
  ' doesn't exist, but we don't care because the 
  ' point is to kill it if it does anyway.
  Kill sFilename
  Err.Clear

  ' code to create a file

End Sub

This isn’t a very robust example. There are many other things besides a file that
doesn’t exist that could cause the Kill statement to fail. The file may be read-only,
there may be a network permissions error, or some other problem.

Handling Errors You Can’t Handle

In most cases you can anticipate the most common errors and build code to deal with
them. The error handling code might be as simple as a message to the user such as
«This field requires a valid date.» In some cases, however, you will encounter
errors you didn’t anticipate and you must find a way to deal with them.

There are two general approaches you can take to handling unanticipated errors:

1. Assume that the error is not fatal to the application.
   
   Most errors will not be fatal to an application. The error may have been
   bad data provided by a user, a file that was not found, etc. Normally these
   kinds of errors can be corrected by the user and the application can continue.
   A default case in an error handler can simply display a message and exit
   the current procedure or continue.

2. Assume that the error is fatal and the application must be terminated.
   
   In some cases, any error may be an application killer. This should be rare
   because this kind of error should be explicitly handled, if necessary by
   providing the user with the tools or information necessary to correct the
   situation. However, if a situation occurs where an unanticipated error is
   fatal, you must be sure to clean up after yourself before you shut down
   the application by unloading all forms and releasing any object variables
   you have created.

You should try to avoid the latter situation at all times. Displaying a message
and shutting down or — worse yet — just pulling the application out from under
the user will not be well received. If you must terminate an application due to
some disastrous situation, be sure to provide as much information to the user
as you can so that the situation can be resolved. An even better option is to
code your error handlers to call code that corrects severe problems.
For example, if you are designing a database application and encounter a
corrupted database file, the error handling code could give the user the
option of attempting to repair the damaged file. If a file cannot be found where
it should be, write code to either look for it or give the user a file open
dialog box so they can tell you where it went.

Raising Your Own Errors

There may be times when you need to generate errors in your code. This happens most often
in class modules, but you can raise an error anywhere in a Visual Basic application.
You raise an error by calling the Raise method of the Err object. Not surprisingly,
the parameters of the Raise method are the same as the properties of the Err object:
Number, Description, Source, HelpContext, and HelpFile. The values you provide
for these parameters are available to error handling code that deals with the error
you generate.

When you raise an error, you should make the information you provide via the Err object
as informative as possible so that error handling code that deals with the error has
the best possible opportunity to handle it.

• Number
  
  You can raise any of the standard VB error numbers or provide your own number. If you
  are raising application-defined errors, you need to add the intrinsic constant vbObjectError
  to the number you raise so that your number does not conflict with built in error
  numbers.

• Description
  
  Make the description as informative as possible. If invalid data is provided, it may
  be helpful to make that data part of the error message.

• Source
  
  The Source provides the name of the object that generated the error.
  For example, if a Jet Database object raises an error, the Source property is
  «DAO.Database».
• HelpContext
  

  If you provide a help file with the component or application, use the HelpContext
  parameter to provide a context ID. This can then be passed on to the MsgBox
  statement so that context sensitive help about the error is available.

• HelpFile
  
  This is the name of the help file and is used in conjunction with the HelpContext
  parameter.

The following example is a hypothetical property procedure for a class module:

' in the declarations section
Private mDate As Date

Public Enum MyClassErrors
  errInvalidDate
  ' other errors
End Enum

' a property procedure
Public Property Let Date(vntDate As Variant)
' a variant is used to allow the property
' procedure to attempt to convert the value
' provided to a date

  If IsDate(vntDate) Then
    mDate = CDate(vntDate)
  Else
    ' invalid data
    Err.Raise _
        Number:=errInvalidDate, _
        Description:=CStr(vntDate) & " is not a valid date.", _
        Source:="Foo.MyClass"
        ' help context and file go here if a help file is available
  End If

End Property

In this example, the property procedure tests for a valid date using the IsDate function.
If the data provided is not a date, an error is raised using the constant from the
error enumeration in the declarations section of the class module and a description
that includes the bad data and the nature of the error.

Summary

Handling run-time errors is something all applications must do if they are to be robust and reliable.

The key points for error handling are:

• There are two steps to handling run-time errors:
  1. Trap the error by enabling an error handler using the On Error statement.
  2. Handle the error by examining the properties of the Err object and writing
     code to deal with the problem.
• Error handlers can be dedicated blocks of code enabled by using On Error Goto
  label or can be inline handlers enabled by using On Error
  Resume Next.
• You can raise your own errors by calling the Raise method of the Err object.
• Do your best to handle run-time errors rather than just inform the user
  of the problem, but if you can’t do anything but display a message, make it
  as informative as possible.
• Avoid terminating the application if at all possible.

The Err object was introduced in Visual Basic 4.0. For backward compatibility, VB
continues to support the Err and Error statements and functions. Any new code
should be using the Err object and legacy code should be converted to use the
Err object.

By Joe Garrick