Ошибка времени выполнения basic

Дорогому All-у доброго времени суток и года!
  • Печать

Страницы: [1]   Вниз

Тема: Правила BASIC не работают в макросах LibreOffice, или почему не едут лыжи?  (Прочитано 9091 раз)

0 Пользователей и 1 Гость просматривают эту тему.

Оффлайн
MAMOHT

Дорогому All-у доброго времени суток и года!
«Всё было хорошо пока не занялся программированием…»
                                        «МАМОНТ. Copyright 11:21 29.06.2012 г.»
Как древний виндузятник порочащий весь и вся Человечную ОС по воле судьбы был приговорён к освоению софта под Линукс. И вот, при попытке написания макросов под LibreOffice, столкнулся с такими вот траблами:

При создании книжного макроса:

Sub MyCursor
  Dim Doc As Object
  Dim Cursor As Object
  Dim sPath As String

  Doc = StarDesktop.CurrentComponent
  Cursor = Doc.Text.createTextCursor()

Вот здесь выскакивает окно сообщения с надписью: «Свойство или метод не найдены: Text»

…..........
…........
  sPath = CurDir$
  MsgBox sPath
А здесь в сообщении чётко указана моя домашняя директория, но НЕ ТА директория в которой СЕЙЧАС открыт документ.

…......
End Sub

Проблема:
Из чьей кожи надо сделать бубен и какие изучить PAS, чтобы при составлении макроса на BASIC в LibreOffice 3.5.4.2 ID сборки: 350m1(Build:2) системы Ubuntu 10.04.4 всё-таки РАБОТАЛО правило Cursor = Doc.Text.createTextCursor() и как мне получить ТУ ТЕКУЩУЮ директорию в которой сейчас открыт АКТИВНЫЙ документ?

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

« Последнее редактирование: 29 Июня 2012, 15:56:47 от Чистый »


Оффлайн
Señor_Gaga

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

Если мне изменяет память — бейсик идет только для msWord.
Для ОО и LO есть свой скриптовый язык.


Оффлайн
MAMOHT

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

Если мне изменяет память — бейсик идет только для msWord.
Для ОО и LO есть свой скриптовый язык.

Вторую часть КАК-БЫ проблемы КАК-БЫ решил. Правда использованием не кратчайшего пути: это КАК-БЫ проехать в Париж через Владивосток. Нашёл описание на 114 странице книги Эндрю Питоньяк (Andrew Pitonyak)OpenOffice.org pro. Автоматизация работы.

Теперь к Señor_Gaga. Здесь точно КТО-ТО ошибается!!!

Переписываю дословно окно сообщения:
«Ошибка времени выполнения BASIC.
Свойство или метод не найдены: TEXT»


Оффлайн
brij

Не могу сейчас точно ответить на Ваш вопрос, но просто вспомнил, что у Питоньяка есть много чего по макросам ЛО. Наверняка, Вам уже это известно, но все же на всякий пожарный  ;) Если дружите с английским, то здесь http://www.pitonyak.org/oo.php/ можно найти очень много полезного, особенно мне когда-то сильно помог его «Macro document» http://www.pitonyak.org/oo.php/AndrewMacro.pdf. Там кстати, есть и его еще незаконченный список параллелей с VBA. Может пригодится.


Оффлайн
Dixi257


  • Печать

Страницы: [1]   Вверх

При запуске самой программы или открытия любого докум

Автор ForumOOo (бот), 21 февраля 2012, 14:01

0 Пользователи и 1 гость просматривают эту тему.

Компонент: Общие вопросы
Версия продукта: 3.3
Сборка: openoffice.org 3.3.0 OOO330m20 (build 9567)
ОС: Windows xp sp3

При запуске самой программы или открытия любого документа с помощью OO выходит окно
«Мои макросы и диалоги.promt Open Office Basic» в этом окне две ошибки
— «Ошибка времени выполнения Basic. Свойство или метод не найдены: CurrentController»
— «Ошибка времени выполнения Basic. Переменная типа Object не установлена»
Закрываю эти сообщения и можно дальше работать.

Тестовый файл: http://forumooo.ru/attachments/upload/err.jpg (200.5 КБ)


Подпись: Марина


Не может быть.

[вложение удалено Администратором]


Hasim, если у вас нет такой проблемы, это не значит, что ее нет у меня.
Я open office уже переустанавливала раз 10, сносила джаву, ставила заново, а проблема осталась.
Как ее победить?


Для начала показать весь файл целиком, а не кусок картинки.


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


Да, в принципе, и этого фрагмента картинки хватает…
Добро пожаловать на форум, Марина!

Скажите, а Promt вы после установки офиса не переустанавливали?
Скорее всего, в настройках офиса (меню Сервис-Настройка-События) на событие «Запуск приложения» записан запуск макроса, формирующего меню переводчика. Проверьте, пожалуйста.

PS. Я думаю, ошибка выскакивает, если просто запускается офис. В случае, если сразу открывается какой-то документ, её быть не должно. Фокус в том, что у любого документа свойство CurrentController есть, а у главного окна — нет. Если мои подозрения верны, то для устранения ошибки достаточно будет

удалить Promt (шутка)

немного доработать макрос regicterContextMenuInterceptor.


Hasim и neft, К своему стыду, я не знаю, как создать пустой файл, чтобы в него ваш макрос вставить.

JohnSUN, Промт я недели две как снесла. А кто вначале раньше был установлен ПРОМТ или ОО я не помню, очередная попытка снести ОО и заново установить была сегодня.
Нашла в «Запуск приложения» в столце «Назначенное действие» 4 каких-то макроса типа promt.***
Они были благополучно удалены. Моя проблема ушла. Я что, все правильно сделала?!


Эта зараза ПРОМТ оказывается прописался в системе. Как его у далить из ОО, чтобы и в дальнейшем, он мне жизнь не портил?

[вложение удалено Администратором]


Да, всё сделала правильно.
Почистить меню можно попробовать через ту же Сервис-Настройка-Меню кнопка Изменить-Удалить.
Или плюнуть на всё и просто удалить профиль пользователя. Раз уж переустанавливала столько раз, значит жалеть не о чем — в топку!


Во оно как! Не знала, не знала. Спасибо за участие, что хотела — сделала :-)


Всегда рады помочь!
Будут вопросы — не стесняйся, здесь все свои  :beer:


Если удаление профиля не поможет, ОБЯЗАТЕЛЬНО проделайте такое:
1. Удаляете (не переустанавливаете — восстанавливаете) Офис через «Панель управления — Установка и удаление прграмм».
2. Вручную из «Program_Files» удаляете папку «OpenOffice 3»
В Program FilesOpenOffice 3.. (даже при удалении всего пакета) остаются расширения, установленные «для всех пользователей. Эти расширения будут подключены к вновь установленному Офису при его 1-м запуске, что будет зафиксировано в Офисном профиле пользователя.
3. Удаляете Офисный профиль пользователя (ссылка «КАК» — у JohnSUN)
4. Устанавливаете Офисный пакет.


  • Форум поддержки пользователей LibreOffice, Apache OpenOffice

  • Главная категория

  • Общее

  • При запуске самой программы или открытия любого докум

Обработка ошибок

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

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

Типы ошибок

Существуют три типа ошибок в программе:

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

Инструкция On Error

Ошибки времени выполнения можно перехватывать внутри подпрограммы. Для этого используется инструкция On Error, которая имеет три формата:

  • On Error GoTo <Метка> — при возникновении ошибки управление передается инструкции, помеченной меткой <Метка>. Метка должна быть допустимым идентификатором, к которому предъявляются такие же требования как и к переменным. Внутри подпрограммы метка указывается в самом начале помечаемой строки и после метки ставится двоеточие. В качестве примера создадим функцию для деления двух целых чисел. Внутри функции предусмотрим обработку ошибки деления на 0:
Function Деление(x As Integer, y As Integer) As Double
   On Error GoTo ПриОшибке
   Деление = x / y
   Exit Function
ПриОшибке:
   Деление = 0
End Function

Если при вызове функции во втором параметре передать значение 0, то управление будет передано в строку, помеченную с помощью метки ПриОшибке. Обратите внимание на то, что метка расположена после инструкции Exit Function. В этом случае код после инструкции Exit Function будет выполнен только в том случае, если возникнет ошибка;

  • On Error Resume Next — при возникновении ошибки управление передается следующей инструкции;
  • On Error GoTo 0 — отключает перехват ошибок.

Если внутри подпрограммы не предусмотрен перехват ошибки, то при возникновении ошибки работа программы прерывается и выводится стандартное окно с описанием и несколькими кнопками: Continue (продолжить), End (завершить выполнение программы), Debug (перейти в режим отладки) и Help (вывод справки).

Инструкция Resume

Инструкция Resume позволяет указать куда следует переходить после обработки ошибки. Инструкция имеет несколько форматов:

  • Resume [0] — управление передается инструкции, вызвавшей ошибку;
  • Resume Next — управление передается инструкции, следующей за инструкцией, вызвавшей ошибку;
  • Resume <Метка> — управление передается инструкции, помеченной меткой <Метка>.

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

Получение информации об ошибке и генерация ошибки

Вся информация о последней ошибке доступна через объект Err. Объект содержит следующие свойства:

  • Number — код ошибки, например, код 11 для ошибки деления на 0. Если ошибки не произошло, то свойство содержит значение 0;
  • Description — описание ошибки, например, строка "Division by zero" для ошибки деления на 0. Пример вывода кода и описания ошибки:
Debug.Print Err.Number; Err.Description
  • Source — название текущего проекта;
  • HelpFile — путь к файлу справки;
  • HelpContext — идентификатор раздела в справочном файле;
  • LastDLLError — системный код ошибки при работе с DLL.

Объект Err содержит следующие методы:

  • Clear() — очищает всю информацию о последней ошибке. Этот метод следует вызвать после успешной обработки ошибки. Информация об ошибке автоматически очищается при выходе из подпрограммы и ряде других случаев;
  • Raise() — позволяет сгенерировать ошибку в программе. Формат метода:
Raise Number[, Source][, Description][, HelpFile][, HelpContext]

В параметре Number указывается код генерируемой ошибки (целое число от 0 до 65 535). Коды от 0 до 512 зарезервированы под системные ошибки, а остальные коды можно использовать под пользовательские ошибки. Чтобы сгенерировать ошибку с пользовательским кодом необходимо сложить код с константой vbObjectError. Остальные параметры являются необязательными и полностью аналогичны одноименным свойствам объекта Err. Пример генерации и обработки пользовательской ошибки:

Sub ГенерацияОшибки()
   On Error GoTo ПриОшибке
   Err.Raise vbObjectError + 513
   Exit Sub
ПриОшибке:
   Debug.Print Err.Number; Err.Description
   ' -2147220991 Automation error
End Sub

Способы поиска ошибок в программе

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

Первое, на что следует обратить внимание, — на объявления переменных. Например, рассмотрим простой пример:

Как вы думаете, какое значение отобразится в окне Immediate после выполнения этого кода? Думаете, что число 10? Не факт! Вот тут-то и кроется проблема не видная на первый взгляд. В первой инструкции присваивается значение переменной x, имя которой набрано на английской раскладке клавиатуры, а вот во второй инструкции выводится значение переменной x, имя которой набрано на русской раскладке клавиатуры. В результате значение присваивается одной переменной, а выводится значение другой переменной. Такие ситуации очень часто встречаются в программах на языке VBA, так как объявлять переменную не обязательно. Чтобы избежать такой ситуации следует обязательно объявлять переменные явным образом. Контроль за соблюдением этого правила можно возложить на компилятор, добавив в начале модуля следующую инструкцию:

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

Option Explicit
...
Dim x As Integer
x = 10
Debug.Print x ' 10

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

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

Dim Массив As Variant, i As Integer, j As Integer
Массив = Array(Array(0, 1), Array(2, 3), Array(4, 5))
For i = 0 To 2
   For j = 0 To 1
      Debug.Print Массив(i)(j)
   Next
Next

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

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

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

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

Метод Print() объекта Debug удобно использовать для вывода промежуточных значений. В этом случае значения переменных вначале выводятся в самом начале программы и производится проверка соответствия значений. Если значения соответствуют, то инструкция с методом Print() перемещается на следующую строку программы и опять производится проверка и т. д. Если значения не совпали, то ошибка возникает в инструкции, расположенной перед инструкцией с методом Print(). Если это пользовательская подпрограмма, то проверку значений производят внутри подпрограммы, каждый раз перемещая инструкцию с выводом значений. На одном из этих многочисленных этапов ошибка обычно обнаруживается. В больших программах можно логически догадаться о примерном расположении инструкции с ошибкой и начать поиск ошибки оттуда, а не с самого начала программы.

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

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

#If MY_DEBUG Then
   ' Здесь размещаем инструкции вывода значений
#End If

Таким образом, меняя значение константы MY_DEBUG с 1 на 0, можно отлючать вывод всех промежуточных значений.

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

Прежде чем начать отладку необходимо пометить строки внутри программы с помощью точек останова. Для добавления точки останова делаем строку активной, а затем из меню Debug выбираем пункт Toggle Breakpoint. Слева от строки появится кружок, обозначающий точку останова. Добавить точку останова можно еще быстрее. Для этого достаточно щелкнуть слева от строки левой кнопкой мыши. Повторный щелчок позволяет удалить точку останова. Кроме того, для добавления или удаления точки отстанова можно воспользоваться клавишей <F9>. Чтобы удалить все точки останова следует из меню View выбрать пункт Clear All Breakpoints.

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

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

При отладке можно контролировать значения отдельных переменных, а не всех сразу. Для этого следует выделить название переменной и из меню Debug выбрать пункт Add Watch. Можно также выделить название переменной и из контектного меню выбрать пункт Add Watch. В открывшемся окне устанавливаем флажок Watch Expression и нажимаем кнопку OK. Значение переменной будет отображаться в окне Watches. Чтобы отобразить окно Watches из меню View выбираем пункт Watch Window. Чтобы отменить отслеживание нужно выделить строку в окне Watches и нажать клавишу <Delete>.

Для пошагового выполнения программы предназначены следующие пункты в меню Debug или соответствующие кнопки на панели инструментов Debug (View | Toolbars | Debug):

  • Step Into (клавиша <F8>) — выполняет переход к следующей инструкции;
  • Step Over — выполняет одну инструкцию. Если в этой инструкции производится вызов подпрограммы, то подпрограмма выполняется за один шаг и отладчик переходит в режим ожидания после выхода из подпрограммы;
  • Step Out — при заходе в подпрограмму этот пункт позволяет выполнить подпрограмму за один шаг и выйти из нее. Отладчик переходит в режим прерывания после выхода из подпрограммы;
  • Run To Cursor — выполняет переход к инструкции, в которой расположен курсор.

Если необходимо посмотреть последовательность вызова подпрограмм, то следует открыть окно Call Stack, выбрав в меню View пункт Call Stack.

Подача звукового сигнала

При возникновении ошибки или при неправильном вводе данных имеет смысл привлечь внимание пользователя звуковым сигналом. Сгенерировать звуковой сигнал позволяет инструкция Beep. Пример:

Dim Результат
Beep
Результат = InputBox("Необходимо ввести значение")

Visual Basic for Applications (VBA)
Статьи по Visual Basic for Applications (VBA)

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

В этой лекции вы узнаете, как:

  • исправлять ошибки времени исполнения с помощью нового обработчика ошибок Try…Catch ;
  • проверять конкретные условия возникновения ошибок с помощью оператора Catch When ;
  • использовать свойства Err.Number и Err.Description для определения исключений;
  • создавать вложенные операторы Try…Catch ;
  • использовать обработчики ошибок в комбинации с защитными техниками программирования;
  • досрочно выходить из обработчиков ошибок с помощью оператора Exit Try.

В
«Отладка программ на Visual Basic .NET»
вы узнали, как распознавать в программах на Microsoft Visual Basic .NET ошибки времени исполнения, и как с помощью инструментов для отладки Microsoft Visual Studio .NET обнаружить в коде программы логические ошибки и другие дефекты. В этой лекции вы узнаете, как создавать блоки кода, которые обрабатывают ошибки времени исполнения. Такие ошибки (также называемые исключениями ) возникают при нормальных условиях работы — например, из-за отсутствия диска в дисководе или отключенного принтера. Блоки кода, обрабатывающие такие ошибки, называются структурными обработчиками ошибок (или структурными обработчиками исключений). Вы можете использовать их для распознавания ошибок времени исполнения при их возникновении в программе, подавления нежелательных сообщений об ошибках и настройки программы так, что она снова сможет получить управление и продолжить работу.

Visual Basic .NET включает блок Try…Catch — новую синтаксическую конструкцию для обработки ошибок. В этой лекции вы узнаете, как с помощью блоков кода Try…Catch перехватывать ошибки времени исполнения и как использовать свойства Err.Number и Err.Description для идентификации конкретных ошибок времени исполнения. Вы также узнаете, как для написания более гибких обработчиков ошибок использовать множественные операторы Catch, создавать вложенные блоки кода Try…Catch и использовать оператор Exit Try для досрочного выхода из блока кода Try…Catch. Техники программирования, о которых вы узнаете, аналогичны синтаксису On Error Goto из предыдущих версий Visual Basic, а структурные обработчики ошибок в настоящий момент предоставляются также языками программирования Java и C++. Наиболее надежные программы на Visual Basic используют несколько обработчиков ошибок для анализа непредвиденных обстоятельств и предоставления пользователям удобной и бесперебойной работы.

Что нового в Visual Basic .NET?

  • Блок кода Try…Catch — это новый способ написания структурных обработчиков ошибок. Хотя вы можете по-прежнему использовать ключевые слова Visual Basic 6, включая On Error Goto, Resume и Resume Next, запись Try…Catch дает возможность избежать потенциальных сложностей конструкций Goto и предлагает очень эффективный способ управления ошибками времени исполнения.
  • Оператор Catch When позволяет проверять конкретные условия программы и обрабатывать в одном блоке кода Try…Catch несколько ошибок времени исполнения.
  • Оператор Exit Try предлагает новый способ выхода из структурных обработчиков ошибок.
  • Visual Basic .NET продолжает предоставлять свойства Err.Number и Err.Description для идентификации ошибок времени исполнения. В дополнение к этому можно использовать новый метод Err.GetException, который возвращает информацию об условии возникновения ошибки, которая привела к остановке выполнения программы.

Обработка ошибок с помощью Try … Catch

Ошибка времени исполнения — или обрушение программы — это неожиданная проблема, возникшая в программе на Visual Basic, после которой она не может продолжать работу. Вы могли видеть обрушение вашей первой программы, если Visual Basic не мог загрузить рисунок из файла, или в предыдущей лекции, когда вы при отладке намеренно внесли в код вашей программы ошибки. Ошибка времени исполнения возникает тогда, когда Visual Basic пытается выполнить оператор, который по какой-то причине не может быть выполнен в том виде, в котором он написан. Это не значит, что Visual Basic не достаточно умен, чтобы справиться с проблемой; это значит, что компилятору Visual Basic не сказали, что делать, если что-то пойдет не так.

К счастью, вы не обязаны мириться со случайными ошибками, которые приводят вашу программу к обрушению. Можно написать специальные процедуры Visual Basic, называемые структурными обработчиками ошибок, которые будут реагировать на ошибки времени исполнения. Обработчик ошибок отслеживает ошибку времени исполнения и говорит программе, как продолжать работу при возникновении этой ошибки. Обработчики ошибок помещаются в процедуры событий, там, где существует возможность возникновения проблемы, или в общие функции или подпрограммы, специально предназначенные для обработки ошибок. (Подробности о написании функций и подпрограмм см. в
«Использование модулей и процедур»
.) Как предполагает их название, обработчики ошибок обрабатывают ошибку с помощью оператора Try…Catch и специального объекта отслеживания ошибок, который называется Err. У объекта Err есть свойство Number, которое идентифицирует номер ошибки, и свойство Description, в котором содержится описание этой ошибки. Например, если ошибка времени исполнения произошла при загрузке файла с диска, обработчик ошибок может отобразить собственное сообщение об ошибке, которое укажет на проблему, и запретить дисковые операции до тех пор, пока эта проблема не будет устранена пользователем.

Когда использовать обработчики ошибок

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

Установка ловушки: оператор Try … Catch

Блок кода, используемый для обработки ошибки времени исполнения, называется Try…Catch. Вы помещаете оператор Try в процедуре события непосредственно перед оператором, о котором вы беспокоитесь, а оператор Catch следует непосредственно за ним и содержит операторы, которые вы хотите выполнить, если произойдет ошибка времени исполнения. Также можно использовать некоторые дополнительные операторы, такие, как Catch When, Finally, Exit Try, а также вложенные блоки кода Try…Catch, которые демонстрируется в этой лекции. Базовый синтаксис обработчика исключений Try…Catch показан здесь.

Оператор Try указывает на начало обработчика ошибок

Try
  Операторы, которые могут вызвать ошибку времени исполнения
Catch
  Операторы, которые выполняются, если ошибка времени исполнения происходит
Finally
  Дополнительные операторы, выполняемые независимо от возникновения ошибки
End Try

где Try, Catch и End Try — это обязательные ключевые слова, а Finally и операторы, которые стоят за ним, необязательны. Заметьте, что программисты иногда называют операторы, находящиеся между ключевыми словами Try и Catch защищенным кодом, так как любые ошибки времени исполнения, возникающие в этих операторах, не приведут к обрушению программы. (Вместо этого Visual Basic выполняет операторы обработки ошибок, расположенные в блоке кода Catch.)

Ошибки путей и дисководов

В следующем примере продемонстрирована обычная ситуация возникновения ошибки времени исполнения — проблема с путем или дисководом. Чтобы выполнить это упражнение, загрузите пример проекта Visual Basic, который я создал для того, чтобы показать, как графические файлы открываются в объекте вывода изображений на форме Windows. Чтобы подготовиться к этому упражнению, вставьте дискету в дисковод A и скопируйте на него файл Fileopen.bmp. (Копию этого файла, а также проект Disk Drive Error, можно найти в папке c:vbnet03sbsГл.9disk drive error.) Вы будете использовать этот диск на протяжении всей лекции, чтобы сгенерировать ошибки времени исполнения и восстанавливаться после них.

I maintain an old application written in VB6. In client’s environment it raises runtime errors which I can’t reproduce under debugger. Is there any way to get the stacktrace or location of error?

I mean, without putting trace statements all over the code like here or adding error handlers for logging to every procedure like here.

It seems to be a simple question.
Sorry.
I just don’t know VB6 very well.
And it is surprisingly hard to google out any information, considering how widely it is (or used to be) used.

Community's user avatar

asked Jul 8, 2009 at 15:34

Tomek Szpakowicz's user avatar

Tomek SzpakowiczTomek Szpakowicz

13.7k3 gold badges32 silver badges55 bronze badges

7

Try compiling to pcode and see if you still get the error. This is one common difference between the debug mode of VB6 and runtime. I used to compile to native and ran into errors that only occurred in runtime. When I switched to pcode I found either the error went away or more likely a new error that reflected the real problem cropped up and was more easily reproduced in debug mode.

If despite that you still getting the error then I really recommend starting at the top of your procedure stack and working you way down using Maero’s suggestion of

On Error Goto Handler
<code>
Exit <routine>
Handler:
Err.Raise Err.Number, "(function_name)->" & Err.source, Err.Description

It is a pain but there is no real way around it.

answered Jul 8, 2009 at 18:29

RS Conley's user avatar

4

The VB6 debugger is flaky sometimes. There are alternatives.

  • You could try Windbg, a free standalone debugger from Microsoft. Compile your VB6 with no optimisation and «create symbolic debug info» (i.e. create PDB files), and you will be able to debug. Here’s a 2006 blog post by a Microsoft guy about using Windbg with VB6, and 2004 blog post by another Microsoft guy with a brief introduction to Windbg.
  • You could also use the Visual Studio 2008 debugger with VB6 and PDB files, e.g. with Visual C++ Express Edition (which is free). See this for more details.
  • Both Windbg and Visual Studio expect the source code to be in exactly the same path on the debug machine as it was on the build machine when the VB6 was built. The easiest way is to build and debug on the same machine. Otherwise you might need to fiddle with SUBST to create virtual drives — or I’m told the serious way is to use a Symbol Server.

Community's user avatar

answered Jul 12, 2009 at 17:21

MarkJ's user avatar

MarkJMarkJ

29.9k5 gold badges67 silver badges111 bronze badges

If you check the «Create Symbolic Debug Info» checkbox on the Project Properties/Compile tab, then you can debug in Visual Studio just like you would a native C++ application.

answered Jul 9, 2009 at 8:31

Ant's user avatar

AntAnt

5,1342 gold badges33 silver badges41 bronze badges

2

It’s been a while, but I don’t think there is a way to get a stack trace in a VB6 application without adding an error handler and outputting the appropriate message. There were some third party tools that would add error handling to an entire application but I believe it just added «On Error Goto» error handlers throughout the code.

Just as an aside, one of the more insidious runtime errors I ever encountered in a VB6 app was when I used a font that didn’t exist on the client’s PC in the property of a control. This generates a runtime error that cannot be trapped in code, so no amount of error handling that I added ever uncovered the error. I finally came across it by chance. Hope this helps.

answered Jul 8, 2009 at 15:46

Bob Mc's user avatar

Bob McBob Mc

1,9701 gold badge33 silver badges38 bronze badges

1

I maintain an old application written in VB6. In client’s environment it raises runtime errors which I can’t reproduce under debugger. Is there any way to get the stacktrace or location of error?

I mean, without putting trace statements all over the code like here or adding error handlers for logging to every procedure like here.

It seems to be a simple question.
Sorry.
I just don’t know VB6 very well.
And it is surprisingly hard to google out any information, considering how widely it is (or used to be) used.

Community's user avatar

asked Jul 8, 2009 at 15:34

Tomek Szpakowicz's user avatar

Tomek SzpakowiczTomek Szpakowicz

13.7k3 gold badges32 silver badges55 bronze badges

7

Try compiling to pcode and see if you still get the error. This is one common difference between the debug mode of VB6 and runtime. I used to compile to native and ran into errors that only occurred in runtime. When I switched to pcode I found either the error went away or more likely a new error that reflected the real problem cropped up and was more easily reproduced in debug mode.

If despite that you still getting the error then I really recommend starting at the top of your procedure stack and working you way down using Maero’s suggestion of

On Error Goto Handler
<code>
Exit <routine>
Handler:
Err.Raise Err.Number, "(function_name)->" & Err.source, Err.Description

It is a pain but there is no real way around it.

answered Jul 8, 2009 at 18:29

RS Conley's user avatar

4

The VB6 debugger is flaky sometimes. There are alternatives.

  • You could try Windbg, a free standalone debugger from Microsoft. Compile your VB6 with no optimisation and «create symbolic debug info» (i.e. create PDB files), and you will be able to debug. Here’s a 2006 blog post by a Microsoft guy about using Windbg with VB6, and 2004 blog post by another Microsoft guy with a brief introduction to Windbg.
  • You could also use the Visual Studio 2008 debugger with VB6 and PDB files, e.g. with Visual C++ Express Edition (which is free). See this for more details.
  • Both Windbg and Visual Studio expect the source code to be in exactly the same path on the debug machine as it was on the build machine when the VB6 was built. The easiest way is to build and debug on the same machine. Otherwise you might need to fiddle with SUBST to create virtual drives — or I’m told the serious way is to use a Symbol Server.

Community's user avatar

answered Jul 12, 2009 at 17:21

MarkJ's user avatar

MarkJMarkJ

29.9k5 gold badges67 silver badges111 bronze badges

If you check the «Create Symbolic Debug Info» checkbox on the Project Properties/Compile tab, then you can debug in Visual Studio just like you would a native C++ application.

answered Jul 9, 2009 at 8:31

Ant's user avatar

AntAnt

5,1342 gold badges33 silver badges41 bronze badges

2

It’s been a while, but I don’t think there is a way to get a stack trace in a VB6 application without adding an error handler and outputting the appropriate message. There were some third party tools that would add error handling to an entire application but I believe it just added «On Error Goto» error handlers throughout the code.

Just as an aside, one of the more insidious runtime errors I ever encountered in a VB6 app was when I used a font that didn’t exist on the client’s PC in the property of a control. This generates a runtime error that cannot be trapped in code, so no amount of error handling that I added ever uncovered the error. I finally came across it by chance. Hope this helps.

answered Jul 8, 2009 at 15:46

Bob Mc's user avatar

Bob McBob Mc

1,9701 gold badge33 silver badges38 bronze badges

1

Понравилась статья? Поделить с друзьями:
  • Ошибка времени виндовс 7 какое обновление
  • Ошибка входа 4003 совкомбанк
  • Ошибка времени вики
  • Ошибка входа 0х00100888 фифа мобайл
  • Ошибка врача стоматолога