Remkomplekty.ru

IT Новости из мира ПК
2 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Обработчик ошибок в vba

Правильная обработка ошибок в VBA (Excel)

Я работаю с VBA уже довольно давно, но я все еще не уверен в обработке ошибок.

хорошая статья одна из CPearson.com

однако мне все еще интересно, был ли способ, которым я раньше делал ошибки, / совершенно неправильным: блок 1

предложение if, потому что если это правда, оно будет выполнено, и если это не удастся, Goto перейдет в Else-part, так как Ubound массива никогда не должно быть нуля или меньше, без ошибки, этот метод работал довольно хорошо до сих пор.

если я правильно понял, это должно быть так: Блок 2

или даже такой: Блок 3

наиболее распространенным способом, который я вижу, является то, что ошибка «Catcher» находится в конце суб, и суб фактически заканчивается до «выхода суб», но, однако, это не немного запутанно, если суб довольно большой, если вы прыгаете вице наоборот, чтобы прочитать код?

блок 4

источник следующего кода: CPearson.com

Должно ли это быть как в блоке 3 ?

Спасибо, что прочитали мой вопрос Приветствия skofgar

5 ответов

Я определенно не буду использовать Block1. Кажется неправильным, что блок ошибок в операторе IF не связан с ошибками.

блоки 2,3 & 4, я думаю, вариации на тему. Я предпочитаю использовать блоки 3 & 4 над 2 только из-за нелюбви к оператору GOTO; я обычно использую метод Block4. Это один из примеров кода, который я использую, чтобы проверить, добавлена ли библиотека Microsoft ActiveX Data Objects 2.8 и если не добавить или использовать более раннюю версию, если 2.8 не доступный.

у вас есть один действительно замечательный ответ от ray023, но ваш комментарий, что это, вероятно, перебор, подходит. Для «более светлой» версии.

блок 1 это, ИМХО, плохая практика. Как уже указывалось osknows, смешивание обработки ошибок с кодом нормального пути не является хорошим. Во-первых, если a новая ошибка возникает, когда есть условие ошибки в действительности вы будете не получите возможность справиться с этим (если вы звоните из обычной это также имеет обработчик ошибок, где выполнение будет «пузыриться»).

Блок 2 похоже на имитацию блока Try / Catch. Это должно быть хорошо, но это не путь VBA. Блок 3 является вариацией на блоке 2.

блок 4 — это голая версия пути VBA. Я бы сильно посоветуйте использовать его или что-то в этом роде, потому что это то, что ожидает любой другой программист VBA, наследующий код. Позвольте представить небольшое расширение, однако:

обратите внимание, что второй Resume . Это трюк, которому я научился недавно: это будет никогда выполнить в обычной обработке, так как Resume оператор отправит выполнение в другое место. Однако это может быть находкой для отладки. При получении уведомления об ошибке выберите отладка (или нажмите Ctl-Break, затем выберите отладка при получении сообщения «выполнение было прервано»). Следующий (выделенный) оператор будет либо MsgBox или следующий оператор. Используйте «Set Next Statement» (Ctl-F9), чтобы выделить голый Resume , нажмите клавишу F8. Это покажет вам ровно где произошла ошибка.

Что касается вашего возражения против этого формата «прыжки вокруг», а) это то, что программисты VBA ожидают, как указано ранее, & B) ваши подпрограммы должны быть достаточно коротким, чтобы не далеко прыгать.

две основные цели для обработки ошибок:

  1. ошибки ловушки вы можете прогнозировать, но не управлять пользователем от выполнения (например, сохранение файла в thumb drive когда thumb диски был удален)
  2. непредвиденные ошибки, пользователя с формой это сообщает им, в чем проблема есть. Таким образом, они могут передать это сообщение для вас, и вы, возможно, сможете чтобы дать им работу, пока вы работайте над исправлением.

Итак, как бы вы сделали это?

прежде всего, создайте форму ошибки для отображения при возникновении непредвиденной ошибки.

это может выглядеть примерно так (FYI: мой называется frmErrors):

обратите внимание на следующие надписи:

  • lblHeadline
  • lblSource
  • lblProblem
  • lblResponse

кроме того, стандартная команда кнопки:

нет ничего впечатляющего в коде для этой формы:

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

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

у вас могут быть ошибки, которые будут настроены только для вашего приложения. Это, как правило, будет краткий список ошибок специально только для вашего приложения. Если у вас еще нет модуля констант, создайте модуль, который будет содержать перечисление пользовательских ошибок. (Примечание: Office ‘ 97 не поддерживает перечисления.). Перечисление должно выглядеть примерно так:

создайте модуль, который выдаст ваши пользовательские ошибки.

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

копия / вставка кода выше может не работать прямо из ворот, но определенно должна дать вам суть.

кстати, если вам когда-нибудь понадобится, чтобы я сделал логотип вашей компании, посмотрите на меня http://www.MySuperCrappyLogoLabels99.com

Я держу вещи простыми:
На уровне модуля я определяю две переменные и устанавливаю одну в имя самого модуля.

в каждой под / функции модуля я определяю локальную переменную

Я установил ThisRoutineName в имя sub или функции

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

в нижней части каждой под / функции я направляю логический поток следующим образом

затем у меня есть отдельный модуль, который я помещаю во все проекты под названием «mod_Error_Handler».

конечный результат-всплывающее сообщение об ошибке, сообщающее мне, в каком модуле, какой soubroutine и какое сообщение об ошибке конкретно было. Кроме того, он также вставит сообщение об ошибке Windows и код.

Блок 2 не работает, потому что он не сбрасывает обработчик ошибок, потенциально вызывая бесконечный цикл. Для правильной работы обработки ошибок в VBA вам нужно Resume инструкция для очистки обработчика ошибок. The Resume также активирует предыдущий обработчик ошибок. Блок 2 терпит неудачу, потому что новая ошибка возвращается к предыдущему обработчику ошибок, вызывая бесконечный цикл.

Блок 3 терпит неудачу, потому что нет Resume оператор, поэтому любая попытка обработки ошибок после этого будет неудача.

каждый обработчик ошибок должен быть завершен выходом из процедуры или Resume заявление. Маршрутизация обычного выполнения вокруг обработчика ошибок сбивает с толку. Вот почему обработчики ошибок обычно находятся внизу.

но вот еще один способ обработки ошибки в VBA. Он обрабатывает ошибку inline как Try/Catch in VB.net есть несколько подводных камней, но правильно управляемый он работает довольно мило.

ключ к этой работе-использовать Resume заявление сразу за другим On Error заявление. The Resume это в обработчике ошибок и отвлекает код EndTry1 метки. Вы должны немедленно установить другой On Error оператор, чтобы избежать проблем, как предыдущий обработчик ошибок будет «возобновить». То есть он будет активен и готов к обработке очередной ошибки. Это может привести к повторению ошибки и вводу бесконечного цикла.

Читать еще:  Ошибка при установке линукс

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

Обработчик ошибок в vba

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

Простите, но — немного словоблудия 🙂

Ошибки в программе

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

Вы обращаетесь к объекту по имени, а объекта с таким именем в коллекции нет

Вы хотите выделить ячеку на одном листе, а этот лист в данный момент не является активным (типичнейшая ошибка новичков в Excel VBA)

Вы хотите удалить отфильтрованные автофильтром строки, а фильтр вообще не вернул записей и удалять нечего

Вы ссылаетесь на элемент массива, который находится за пределами его границ.

Вы пытаетесь присвоить переменной значение, которое оно не может хранить. Например, переменной типа Long нельзя присвоить строковую константу или переменной типа Integer присвоить знанчение превышающее число 32767 .

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

Continue (продолжить) — этот пункт во время возникновения ошибки всегда не активен. Он активен, когда по ходу выполнения программы вы использовали оператор Stop . Кстати это очень полезный оператор для отладки программы.

End (завершить) — завершение исполнения программы

Debug (отладка) — переход в режим отладки, в котором можно посмотреть, на каком операторе возникла ошибка, что содержат переменные, можно даже перетащить жёлтую полоску, подсвечивающую текущий оператор, назад, и модифицировать знанчение переменных через окно Immediate window (впрочем это экзотика). В общем случае кнопка Debug позволяет посмотреть, где случилась ошибка и попытаться понять почему так случилось.

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

Почему вообще в коде возникают ошибки?

Много ошибок во время написания кода возникает по невнимательности или не совсем адекватного понимания того, что делаешь. Таких ошибок, как правило, очень много, особенно у начинающих программистов, но эти ошибки довольно легко отловить и исправить, так как, пока вы их не исправите, ничего не работает. Ну, например, вы должны извлечь данные из 5-го столбца, а вы извлекаете из 6-го, а их там банально нет. Ясно, что вы это очень быстро заметите.

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

Тонкие логические ошибки. Чем сложнее программа, тем больше шансов, что модель задачи в вашей голове, ваша программа и реальность не совсем согласованы между собой. Пока вы не достигните достаточного погружения в задачу вы такие ошибки не найдёте и не исправите. Порой на это уходит много времени. Но это характерно для сложных задач.

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

Задачи механизмов обработки ошибок

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

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

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

Файл примера

Скачать

Код без обработки ошибок

Вот простой пример с потолка. Если вызвать Example_00 , то она прекрасно отработает без ошибок и вернёт это:

В функцию GetCalories передаётся строка с блюдом, а она должна вернуть его калорийность, сверившись с таблицей в A1:B7 .

Давайте поищем слабые места в этом коде. Первое, что должно прийти в голову — если мы ищем, то, что произойдёт, если мы не найдём? А произойдёт, конечно же, ошибка. Её инициирует метод Match .

Ещё одно слабое место этой подпрограммы: функция возвращает вещественный тип Double , и даже, если поиск оказался удачным, то в Cells(intRow, 2) может случайно находиться текстовая строка, а потому, когда вы числовому типу попытаетесь присвоить строковый тип, также произойдёт ошибка. И, если вы второй ошибки сможете избежать за счёт дополнительного оператора if с проверкой через IsNumber (), то избежать первой ошибки таким способом нельзя. Что же делать? А вот тут на сцену выходят операторы обработки ошибок.

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

Читать еще:  C2131 ошибка мерседес

Автономный подход

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

Итак, что тут сделано:

Сразу после объявления функции GetCalories_v1 идёт оператор on error resume next , который в случае возникновения в каком-либо месте ошибки, предписывает VBA просто передавать управление на следующий оператор, идущий после ошибочного.

Мы объявили переменные. Необъявленные переменные получают тип Variant и значение по умолчанию Empty . Объявленные переменные числовых типов инициируются нулём, строковые — пустой строкой, то есть я наперёд знаю, что они содержат, а это хорошо для обработки ошибок.

На вызове метода WorksheetFunction.Match у нас возникает ошибка, так как искомого значения в таблице нет. А это, между прочим, был оператор присваивания ( = ). Прежде, чем левой части оператора присваивания ( intRow ) что-то будет присвоено, необходимо вычислить правую часть оператора присваивания ( WorksheetFunction.Match . ), а поскольку в процессе этого вычисления возникает ошибка, то переменная intRow остаётся такой, какой была! А, как я уже сказал, VBA автоматически её инициализирует нулём до начала исполнения подпрограммы. Получается, что, если в этом операторе возникнет ошибка, то в intRow будет ноль. Если ошибки во время поиска не возникнет, то ноля там не будет ни при каких раскладах, так как строки на листе нумеруются с единицы.

И вот этот ноль мы и контролируем, добавляя оператор If . Если intRow больше нуля, то WorksheetFunction.Match отработала штатно, а если нет — то работу подпрограммы надо прерывать, но об этом чуть позже.

Далее мы помним, что Cells(intRow, 2) может теоретически вернуть строковое значение, которое вызовет ошибку Type missmatch при присвоении переменной типа Double ( GetCalories_v1 ), поэтому мы вставляем дополнительную проверку промежуточной переменной varTemp тому, что она числовая. И если это так, то присваиваем GetCalories_v1 значение из varTemp .

В случае возникновения любой ошибки внутри GetCalories_v1 она просто вернёт ноль. Почему ноль? Потому что переменная GetCalories_v1 тоже инициализируется нулём и об этом не надо заботиться, а в случае ошибки она останется в неприкосновенности.

Соответственно родительский код (в нашем случае его роль играет процедура Example_01 ) должен проверить, а не вернёт ли GetCalories_v1 ноль, и быть готовым к этой ситуации.

А вот теперь тонкий момент, который не все понимают. Почему я использовал промежуточные переменные intRow и varTemp ? Вроде бы есть очевидный ответ — чтобы не вычислять значение выражений с Match и Cells 2 раза. Отчасти это, конечно, так. Но это, в данном случае, не главная причина. Главная причина в том, что такой код

вызовет неправильное поведение программы. Если у нас Match вызовет исключение, то VBA передаст управление на СЛЕДУЮЩИЙ оператор, а следующий оператор в данном случае это то, что идёт после Then — присваивание переменной varTemp значения. Таким образом наша проверка на наличие ошибки сработает с точностью до наоборот, передав управление в ту часть кода, которая должна быть защищена от ситуации, когда Match не нашла строку в таблице. Вот почему важно в операторе If не иметь ничего такого, что могло бы вызвать ошибку.

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

Выносной подход

Данный метод основан на том, что, когда возникает ошибка, то VBA передаёт управление на специальный участок кода — обработчик ошибок, который обычно размещают в конце подпрограммы. Это может выглядеть так:

Обратите внимание, что:

Оператор on error теперь в случае ошибки предписывает передавать управление на метку ErrorHandler , которая объявлена в конце кода процедуры GetCalories_v2

В коде мы никак не заботимся о каких-либо проверках. Возникла ошибка? Иди на метку — там разберутся.

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

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

Что лучше?

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

Универсальны обработчик ошибок для VBA

Глобальный обработчик ошибок. Если отключить обработчик ошибок в одной из процедур, будет ли он работать в других?
Есть какой то код Sub main On error goto ErrorLine ‘тут какой-то код call fng_1 ‘тут.

Как в VBA-коде установить обработчик события для подчинённой формы?
Привет, друзья! Конкретно меня интересует событие BeforeUpdate для подчинённой формы (Subform).

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

Обработчик ошибок
Обрабатывает ли оператор on error ошибки типа compile error (к примеру syntax error) или только.

Решение

На любую строку можно вернуться так:

Только метки? Что-нибудь типа next -1 нету?

Добавлено через 4 минуты
Может определить строку, в которой ошибка, а потом вернуться к (номер строки с ошибкой -1)?

ставиш метку, перед сомнительной строчкой
но при этом в процедуре долна быть объявленна инструкция
On Error GoTo метка

или так
on error resume next
x=x/0
if err then

Добавлено через 3 минуты
я вообще сделал свой класс
для обработки ошибок
правда некоторые не поняли, что и зачем

Добавлено через 6 минут
вот пример, ошибка-метка

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

— обычно это бессмысленно.

ты лучше поменяй на другое имя метки, это имя зарегестрированного класса рантайма
и могут быть нестыковки

Читать еще:  Ошибка протокола лицензирования rdp

и begin, но оно будет игнориться .. ну это твоё конечно дело

Решение

Vol4_OK, делай вот так:

Заказываю контрольные, курсовые, дипломные и любые другие студенческие работы здесь.

Обработчик ошибок
Всем привет! Наверняка же кто-то уже писал универсальный обработчик ошибок? Типа: . invoke.

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

Обработчик ошибок
error_reporting(E_ALL); // функция обработки ошибок function myErrorHandler($errno, $errstr.

Обработчик ошибок
Привет, а где можно ли както задать обработчик ошибок? Например у нас есть подключение к бд.

Шаг 12 — Обработка ошибок VBA

Программирование это как хождение по минному полю. Неизвестно где взорвешься. Наверно так. Вы наслышаны о том, что Windows напичкан ошибками, о том, что среда разработки, любая при том — тоже. Мне попадались исследования на эту тему. Типа, что на каждые 1000строк кода одна ошибка, у хорошего программиста естественно :-). В общем, это закон такой. Все равно ошибешься где-нибудь. Проводя аналогию между женщиной и компьютером :-))) В общем понятно.

Для обработки ошибок в VBA и VB есть специальный оператор On Error. Его задача при возникновении ошибки передать управление в то место (процедура или кусок кода), в котором это ждут. Посмотрим пример:

On Error GoTo Errors1

Dim x As Integer

Dim a As Integer

Dim c As Double

MsgBox (» Этого не должно быть»)

MsgBox («Ну ты блин Тикурила Даещь»)

В данном примере при возникновении ошибки управление передается по метке Errors1 и дальше выполняется код. Я понимаю, что прерывать функцию из-за ошибки не всегда надо. И не только я так думаю, создатели VBA тоже так считали, и поэтому есть оператор Resume Next. Этот оператор реализует небезызвестный принцип — Ни шагу назад. Выполнение пойдет дальше, несмотря на ошибку.

On Error GoTo Errors1

Dim x As Integer

Dim a As Integer

Dim c As Double

MsgBox («Ну ты блин Тикурила Даещь»)

А вот, если Вы вообще не хотите ничего говорить по поводу ошибки, то можете поступить очень сурово. Вот так. Я рекомендую применять это для бухгалтерских расчетов. Ни кто и не догадается :-)))

On Error Resume Next

Dim x As Integer

Dim a As Integer

Dim c As Double

Над резюме можно немного поэкспериментировать, вот возможные описания:

Пример ниже будет упорно требовать, чтобы ввели число отличное от 0:

On Error GoTo Error1

Dim x As Integer

Dim a As Integer

Dim c As Double

a = Str(InputBox(«введите число»))

MsgBox («думай о программировании, а не о женщинах»)

a = Str(InputBox(«введите число»))

Шаг 13 — Объект Err

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

On Error GoTo Error1

MsgBox «Error detected»

Итак, Number — это номер ошибки Source, где она появилась, а Description описание. В данном случае Вам скажут о выходе за гарницу массива. Вот это здорово. Особенно при создании программ. Получить такое сообщение пользователю не очень приятно, а вот программисту :-)) даже думать не надо.

У объекта Err есть метод очистки Clear, он все очишает. Вот в этом случае Вы не получите никаких сообщений. После обработки ошибки неплохо применить этот метод. Так, ради профилактики.

On Error GoTo Error1

MsgBox «Error detected»

Нельзя не сказать, что этот объект автоматически очистится после ..

При отладке или специально в программе вы и сами можете сгенирировать ошибку методом Raise, только надо знать, что ошибки до 1000 зарезервированы VBA, а максимальный код 65535. Любое правило подвержено изменениям и поэтому есть специальная константа, от которой вы можете сложением получать коды ошибок. Она называется vbObjectError.

excel-vba Обработка ошибок

пример

Хорошая обработка ошибок не позволяет конечным пользователям видеть ошибки времени выполнения VBA и помогает разработчику легко диагностировать и исправлять ошибки.

Существует три основных метода обработки ошибок в VBA, два из которых следует избегать для распределенных программ, если это специально не требуется в коде.

По ошибке GoTo 0

Если в вашем коде не установлена ​​ошибка, On Error GoTo 0 является обработчиком ошибок по умолчанию. В этом режиме любые ошибки времени выполнения запускают типичное сообщение об ошибке VBA, позволяющее либо закончить код, либо ввести режим debug , идентифицируя источник. При написании кода этот метод является самым простым и полезным, но его всегда следует избегать для кода, который распространяется среди конечных пользователей, поскольку этот метод очень непригляден и затруднен для понимания конечными пользователями.

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

Если бы мы не использовали GetObject вызов On Error Resume Next и приложение Powerpoint еще не было открыто, метод GetObject бы ошибку. Таким образом, для устранения двух экземпляров приложения необходимо было On Error Resume Next .

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

Вкл. Ошибка GoTo

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

  • . Нижеприведенная подпрограмма демонстрирует синтаксис вызова On Error GoTo
  • .

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

    Если вы выйдете из своего метода с кодом обработки ошибок, убедитесь, что вы очистили:

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

  • Ссылка на основную публикацию
    ВсеИнструменты
    Adblock
    detector
    ×
    ×