Remkomplekty.ru

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

Ошибка 75 vba

Ошибка 75 vba

This worksheet uses an OnTime event to check for the presence of an text file every 8 seconds and then read in the contents. I’ve checked everthing but can’t figure out why it’s crashing on my XP laptop but works fine on Win7. I just get a message saying excel needed to close.

I’ve checked all the code to look for obvious signs of a memory leak but can’t find any objects I’m not destroying properly. I checked memory usage on task manager and it does increase a little over time but the crash happens way before any memory gets used up.

Bpth machines are running Office 2007 Home & Student. The XP Machine is a little Sony Vaio notebook with a 1.06 ghz processor and 1GB RAM whereas the Win7 laptop is a much faster beast, although nothing is telling me its a performance issue. On the notebook I use tuneup utilities to get it running pretty well.

On Opening you have to click the Live Score option to start the timer. Before that the path on Settings B28/B29 needs to be any valid folder on your machine. It just looks for the presence of a file called score.flg and takes no further action if it can’t find it.

If anyone could take a look and offer some advice I’d really appreciate it.

I should also say the crash happens even when there is no file found by the code called by the timer so the code which would open and read in the file is not even being called.

I’ve done some more troubleshooting on this and I now think the problem is related to the display of one of the user forms. I’m seeing an intermittant problem whereby it displays File/Path Access Error and you are unable to bring the form up in VB editor. Closing the worksheet and reopening fixes it but eventually the problem comes back. The file is being launched from the desktop, not a network share or anything and I can’t think of any reason for this strange message. Google hasn’t been much help either. Anyone have any ideas why this could be happening?

I don’t see any checking of any file in the .ontime macro.
It only contains ‘calculate’

After a lot more investigating I’ve now found this is nothing to do with the ontime routine. It’s a little known bug affecting Excel 2007 workbooks containing user forms. After being open for a while the workbook generates a Run Time Error 75 (Path/File Access Error). Shortly after this the workbook would crash. My code was failing because the ontime routine was saving the workbook periodically and any attempt to save the workbook after the path/file access error instantly causes the workbook to crash.

The problem seems to be specific to Excel 2007 and I’ve found one affected user suggesting an upgrade to 2010 fixed it for them. Most people affected seem to say it only happens on XP (me included) but worryingly someone has also reported it on Win7.

There is no known fix for Excel 2007 users. Someone advised you could hide user forms instead of unloading them but that didn’t work for me. I’ve tried everything to make it work but am finally giving up. I’ll change the thread title to better reflect the issue.

Where is the evidence that this is a bug, rather than a code error?

Here is a link to the best thread I found on the subject:

That was a trial version of Excel 2007. Hardly definitive evidence of an ongoing bug.

FWIW though, for any intermittent code errors, I would generally recommend cleaning your workbook (using Code Cleaner) or even rebuilding it in a new workbook.

Personally I think the evidence is pretty good. In that thread instructions were given as to how to recreate the problem in a new workbook and another user was able to do exactly that. I’ve already tried recreating my workbook myself from a new workbook and new user forms and the problem is still there. In all my research on the Run Time 75 Path/File Access error over the last few days all I have found is confusion and frustration from people and no fixes being found by any of them.

You’ve shown a few people experiencing an intermittent issue, but you yourself have it working in Excel 2007 on a different machine, which would imply to me that if there is a bug, it is not necessarily in 2007. It may be an issue with the OS, or a hardware conflict.

Don’t get me wrong — Excel 2007 is a buggy piece of **** in my opinion and I try never to use it, but I am not convinced that that is where this bug lies. (I note the coincidence of one user in that thread mentioning the error occurring after his screensaver kicked in for instance)

Originally Posted by OnErrorGoto0:
You’ve shown a few people experiencing an intermittent issue, but you yourself have it working in Excel 2007 on a different machine, which would imply to me that if there is a bug, it is not necessarily in 2007. It may be an issue with the OS, or a hardware conflict.

Don’t get me wrong — Excel 2007 is a buggy piece of **** in my opinion and I try never to use it, but I am not convinced that that is where this bug lies. (I note the coincidence of one user in that thread mentioning the error occurring after his screensaver kicked in for instance)

I think we will have to agree to disagree on this. In my opinion this is a bug that’s been found in Excel — they (different users) even recreated it with a simple new workbook with one form and one line of code. If a hardware conflict or an OS issue is causing Excel to do this (which I personally think is unlikely) then it is still a bug in Excel in my mind.

More to the point — can anyone offer any suggested fixes other than those already mentioned?

It’s more likely to be a bug in the Forms Library (FM20.dll) which is not actually part of Excel, I would suggest, but never mind. If it’s not related to OS or hardware, why does it work on one of your machines?

The only other thing I can suggest that you might try is not using the default instancing of the forms — declare a variable and use that, then destroy the variable when done.

Originally Posted by OnErrorGoto0:
It’s more likely to be a bug in the Forms Library (FM20.dll) which is not actually part of Excel, I would suggest, but never mind. If it’s not related to OS or hardware, why does it work on one of your machines?

The only other thing I can suggest that you might try is not using the default instancing of the forms — declare a variable and use that, then destroy the variable when done.

I’m not saying it’s not related to OS or Hardware, I’m just saying Excel seems to behave differently on a Win7 machine to an XP machine, but I still say this is a bug in Excel. Anyway, that’s just pedantics really.

Thanks for the suggestion. I tried creating a new instance of the form then destroying it afterwards, I even tried not loading any of the forms at all (commented out all lines with .show) but the very fact the forms exist in the workbook seems to be enough to crash it.

When I get home tonight I’m going to try and recreate the simple workbook and single userform described by those other users to see if that errors too, although I’m not sure what extra knowledge that is going give me. I’ve tried repairing Excel too. I hate to be beaten but it looks like I have been on this occassion.

Did I misunderstand that then?

That would appear to be a whole new issue, or were you testing this in the same session where you had already shown the form(s)?

Also, just to check, when you say «I tried creating a new instance of the form then destroying it afterwards», can you specify the code you used, please?

If you can show this to be a replicable bug (a demo workbook would be ideal) under a specific OS, then I will file it as a bug, though I cannot make any promises that MS will pay attention.

Читать еще:  Сортировка одномерного массива паскаль

Как исправить ошибку Microsoft Excel 75

Совместима с Windows 2000, XP, Vista, 7, 8 и 10

Признаки ошибки 75

  • Появляется сообщение «Ошибка 75» и окно активной программы вылетает.
  • Ваш компьютер часто прекращает работу после отображения ошибки 75 при запуске определенной программы.
  • Отображается “Excel Error 75”.
  • Windows медленно работает и медленно реагирует на ввод с мыши или клавиатуры.
  • Компьютер периодически «зависает» на несколько секунд.

Такие сообщения об ошибках 75 могут появляться в процессе установки программы, когда запущена программа, связанная с Microsoft Corporation (например, Microsoft Excel), при запуске или завершении работы Windows, или даже при установке операционной системы Windows. Отслеживание момента появления ошибки 75 является важной информацией при устранении проблемы.

Причины ошибки 75

  • Поврежденная загрузка или неполная установка программного обеспечения Microsoft Excel.
  • Повреждение реестра Microsoft Excel из-за недавнего изменения программного обеспечения (установка или удаление), связанного с Microsoft Excel.
  • Вирус или вредоносное ПО, которые повредили файл Windows или связанные с Microsoft Excel программные файлы.
  • Другая программа злонамеренно или по ошибке удалила файлы, связанные с Microsoft Excel.

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

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

star rating here

Как исправить ошибку Microsoft Excel 75

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

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

Шаг 1: Восстановить записи реестра, связанные с ошибкой 75

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

В связи с подобным риском мы настоятельно рекомендуем использовать надежные инструменты очистки реестра, такие как WinThruster [Загрузить] (разработанный Microsoft Gold Certified Partner), чтобы просканировать и исправить любые проблемы, связанные с Ошибка 75. Используя очистку реестра [Загрузить], вы сможете автоматизировать процесс поиска поврежденных записей реестра, ссылок на отсутствующие файлы (например, вызывающих ошибку %%error_name%%) и нерабочих ссылок внутри реестра. Перед каждым сканированием автоматически создается резервная копия, позволяющая отменить любые изменения одним кликом и защищающая вас от возможного повреждения компьютера. Самое приятное, что устранение ошибок реестра [Загрузить] может резко повысить скорость и производительность системы.

Предупреждение: Если вы не являетесь опытным пользователем ПК, мы НЕ рекомендуем редактирование реестра Windows вручную. Некорректное использование Редактора реестра может привести к серьезным проблемам и потребовать переустановки Windows. Мы не гарантируем, что неполадки, являющиеся результатом неправильного использования Редактора реестра, могут быть устранены. Вы пользуетесь Редактором реестра на свой страх и риск.

Перед тем, как вручную восстанавливать реестр Windows, необходимо создать резервную копию, экспортировав часть реестра, связанную с Ошибка 75 (например, Microsoft Excel):

  1. Нажмите на кнопку Начать.
  2. Введите «command» в строке поиска. ПОКА НЕ НАЖИМАЙТЕENTER!
  3. Удерживая клавиши CTRL-Shift на клавиатуре, нажмите ENTER.
  4. Будет выведено диалоговое окно для доступа.
  5. Нажмите Да.
  6. Черный ящик открывается мигающим курсором.
  7. Введите «regedit» и нажмите ENTER.
  8. В Редакторе реестра выберите ключ, связанный с Ошибка 75 (например, Microsoft Excel), для которого требуется создать резервную копию.
  9. В меню Файл выберите Экспорт.
  10. В списке Сохранить в выберите папку, в которую вы хотите сохранить резервную копию ключа Microsoft Excel.
  11. В поле Имя файла введите название файла резервной копии, например «Microsoft Excel резервная копия».
  12. Убедитесь, что в поле Диапазон экспорта выбрано значение Выбранная ветвь.
  13. Нажмите Сохранить.
  14. Файл будет сохранен с расширением .reg.
  15. Теперь у вас есть резервная копия записи реестра, связанной с Microsoft Excel.

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

Мы не несем никакой ответственности за результаты действий, совершенных по инструкции, приведенной ниже — вы выполняете эти задачи на свой ​​страх и риск.

Ошибка при работе с файлами

Ошибка при работе с файлами
Всем привет! Подккажите, плиз, что у меня неправильно в коде: #include <cstdlib> #include.

Ошибка при работе с файлами
Необходимо, создать текстовый файл со случайным именем в диапазоне 8 символов, латиница. Вот.

Ошибка при работе с файлами
Вечер добрый! Есть код: string test; StreamReader rr =.

Ошибка при работе с файлами
не могу разобраться procedure TForm1.BitBtn1Click(Sender: TObject); var.

findeler, в некоторых случаях использование VBA-функции «Dir» сложно для понимания для непрограммистов. Я помню получал какие-то непонятные результаты при использовании «Dir». Не используйте для узнавания: существует папка или нет — VBA-функции «Dir», а используйте библиотеку «Windows Script Host Object Model» и объект «FileSystemObject».

Думаю, что в интернете есть примеры работы с этим объектом. Если не найдёте, то спросите здесь.

Странно, с чего бы это.

Потому что Вы 2 раза пытаетесь создать одну и ту же папку.

Ваша конструкция проверки папки всегда дает true, потому, что неверно написана и в результатах всегда кроме обычных папок будет выдавать «.» и «..» (то о чем писал Скрипт). Здесь не буду объяснять, что это такое.

проблема в условии

Решение

findeler, потому что у Google Диск-а папка скрытая, а Вы не проверяете этот флаг.
Нужно использовать сумму флагов:

Поправка: там она скрытая (vbSystem).

ikki, без разницы, можно и константой.
20. Или 55 для универсальности.

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

Ошибка при работе с файлами
Дан код. Необходимо при работе с фалом вывести на экран тех, кто достиг пенсионного возраста. При.

Ошибка при работе с файлами
Всем привет! Кто подскажет, почему не работает этот код: FILE *file; int i = 0; if((file =.

Ошибка при работе с файлами
Столкнулся с такой проблемой, что если выбран FileMode.OpenOrCreate, то значения в массив выводятся.

Ошибка в C++ Builder 10 при работе с файлами
ошибка: Unit3.cpp(57): E2094 ‘operator<<‘ not implemented in type ‘fstream’ for arguments of type.

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

Ошибка в программе при работе с файлами
Нужно сначала записать в файл 5 компонент целочисленного типа, далее нужно посчитать их сумму. Вот.

Ошибка 75 vba

This worksheet uses an OnTime event to check for the presence of an text file every 8 seconds and then read in the contents. I’ve checked everthing but can’t figure out why it’s crashing on my XP laptop but works fine on Win7. I just get a message saying excel needed to close.

I’ve checked all the code to look for obvious signs of a memory leak but can’t find any objects I’m not destroying properly. I checked memory usage on task manager and it does increase a little over time but the crash happens way before any memory gets used up.

Bpth machines are running Office 2007 Home & Student. The XP Machine is a little Sony Vaio notebook with a 1.06 ghz processor and 1GB RAM whereas the Win7 laptop is a much faster beast, although nothing is telling me its a performance issue. On the notebook I use tuneup utilities to get it running pretty well.

On Opening you have to click the Live Score option to start the timer. Before that the path on Settings B28/B29 needs to be any valid folder on your machine. It just looks for the presence of a file called score.flg and takes no further action if it can’t find it.

If anyone could take a look and offer some advice I’d really appreciate it.

I should also say the crash happens even when there is no file found by the code called by the timer so the code which would open and read in the file is not even being called.

I’ve done some more troubleshooting on this and I now think the problem is related to the display of one of the user forms. I’m seeing an intermittant problem whereby it displays File/Path Access Error and you are unable to bring the form up in VB editor. Closing the worksheet and reopening fixes it but eventually the problem comes back. The file is being launched from the desktop, not a network share or anything and I can’t think of any reason for this strange message. Google hasn’t been much help either. Anyone have any ideas why this could be happening?

Читать еще:  550 overquoted ошибка

I don’t see any checking of any file in the .ontime macro.
It only contains ‘calculate’

After a lot more investigating I’ve now found this is nothing to do with the ontime routine. It’s a little known bug affecting Excel 2007 workbooks containing user forms. After being open for a while the workbook generates a Run Time Error 75 (Path/File Access Error). Shortly after this the workbook would crash. My code was failing because the ontime routine was saving the workbook periodically and any attempt to save the workbook after the path/file access error instantly causes the workbook to crash.

The problem seems to be specific to Excel 2007 and I’ve found one affected user suggesting an upgrade to 2010 fixed it for them. Most people affected seem to say it only happens on XP (me included) but worryingly someone has also reported it on Win7.

There is no known fix for Excel 2007 users. Someone advised you could hide user forms instead of unloading them but that didn’t work for me. I’ve tried everything to make it work but am finally giving up. I’ll change the thread title to better reflect the issue.

Where is the evidence that this is a bug, rather than a code error?

Here is a link to the best thread I found on the subject:

That was a trial version of Excel 2007. Hardly definitive evidence of an ongoing bug.

FWIW though, for any intermittent code errors, I would generally recommend cleaning your workbook (using Code Cleaner) or even rebuilding it in a new workbook.

Personally I think the evidence is pretty good. In that thread instructions were given as to how to recreate the problem in a new workbook and another user was able to do exactly that. I’ve already tried recreating my workbook myself from a new workbook and new user forms and the problem is still there. In all my research on the Run Time 75 Path/File Access error over the last few days all I have found is confusion and frustration from people and no fixes being found by any of them.

You’ve shown a few people experiencing an intermittent issue, but you yourself have it working in Excel 2007 on a different machine, which would imply to me that if there is a bug, it is not necessarily in 2007. It may be an issue with the OS, or a hardware conflict.

Don’t get me wrong — Excel 2007 is a buggy piece of **** in my opinion and I try never to use it, but I am not convinced that that is where this bug lies. (I note the coincidence of one user in that thread mentioning the error occurring after his screensaver kicked in for instance)

Originally Posted by OnErrorGoto0:
You’ve shown a few people experiencing an intermittent issue, but you yourself have it working in Excel 2007 on a different machine, which would imply to me that if there is a bug, it is not necessarily in 2007. It may be an issue with the OS, or a hardware conflict.

Don’t get me wrong — Excel 2007 is a buggy piece of **** in my opinion and I try never to use it, but I am not convinced that that is where this bug lies. (I note the coincidence of one user in that thread mentioning the error occurring after his screensaver kicked in for instance)

I think we will have to agree to disagree on this. In my opinion this is a bug that’s been found in Excel — they (different users) even recreated it with a simple new workbook with one form and one line of code. If a hardware conflict or an OS issue is causing Excel to do this (which I personally think is unlikely) then it is still a bug in Excel in my mind.

More to the point — can anyone offer any suggested fixes other than those already mentioned?

It’s more likely to be a bug in the Forms Library (FM20.dll) which is not actually part of Excel, I would suggest, but never mind. If it’s not related to OS or hardware, why does it work on one of your machines?

The only other thing I can suggest that you might try is not using the default instancing of the forms — declare a variable and use that, then destroy the variable when done.

Originally Posted by OnErrorGoto0:
It’s more likely to be a bug in the Forms Library (FM20.dll) which is not actually part of Excel, I would suggest, but never mind. If it’s not related to OS or hardware, why does it work on one of your machines?

The only other thing I can suggest that you might try is not using the default instancing of the forms — declare a variable and use that, then destroy the variable when done.

I’m not saying it’s not related to OS or Hardware, I’m just saying Excel seems to behave differently on a Win7 machine to an XP machine, but I still say this is a bug in Excel. Anyway, that’s just pedantics really.

Thanks for the suggestion. I tried creating a new instance of the form then destroying it afterwards, I even tried not loading any of the forms at all (commented out all lines with .show) but the very fact the forms exist in the workbook seems to be enough to crash it.

When I get home tonight I’m going to try and recreate the simple workbook and single userform described by those other users to see if that errors too, although I’m not sure what extra knowledge that is going give me. I’ve tried repairing Excel too. I hate to be beaten but it looks like I have been on this occassion.

Did I misunderstand that then?

That would appear to be a whole new issue, or were you testing this in the same session where you had already shown the form(s)?

Also, just to check, when you say «I tried creating a new instance of the form then destroying it afterwards», can you specify the code you used, please?

If you can show this to be a replicable bug (a demo workbook would be ideal) under a specific OS, then I will file it as a bug, though I cannot make any promises that MS will pay attention.

Ошибка 75 vba

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

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

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

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

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

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

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

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

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

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

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

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

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

Читать еще:  Ошибка login failed

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

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

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

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

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

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

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

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

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

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

Файл примера

Скачать

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

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

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

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

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

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

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

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

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

Сразу после объявления функции 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 .

Что лучше?

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

Ссылка на основную публикацию
Adblock
detector