Добавьте кнопку Run To Cursor к панели инструментов Debug
Подобно отладчику Visual C++, отладчик Visual Basic позволяет выполнять программу до позиции курсора. По умолчанию команда Run To Cursor назначается сочетанию клавиш <Ctrl>+<F8>, но многим нравится при отладке использовать мышь, а этой замечательной команды нет на панели инструментов Debug. На вкладке Command диалогового окна Customize выберите категорию Debug и перетащите кнопку Run To Cursor на панель инструментов Debug.
В Visual Basic 6 можно заметить, что если создать кнопку Run To Cursor на панели инструментов, то в окне всплывающей подсказки для пункта меню Run To Cursor отображается текст "Step To Cursor" (Шаг к курсору). Просто игнорируйте эту подсказку (т. к. кнопка все еще выполняет команду Run To Cursor). Вы просто видите "маленькую ошибку".
Групповые проекты как способ перехода к отладке
В Visual Basic 5 была введена концепция группового проекта. Групповой проект позволяет разместить все ActiveX-компоненты вместе с их тестовым окружением и главный ЕХЕ-файл (при условии, что его программа написана на языке Visual Basic) в одном проекте. Если все компоненты помещены в один проект, становится возможным пошаговое выполнение ЕХЕ-файла с проходом через все элементы управления и библиотеки DLL. В качестве примера просмотрите файл TESTER.VBG (часть кода из главы 13) на сопровождающем компакт-диске.
Окна отладчика Visual Basic
До сих пор мы говорили главным образом об ограничениях VB-отладчика, а не о его сильных сторонах. Но, как сказано в начале этой главы, этот отладчик имеет несколько свойств, которые разработчикам нравятся. Для начинающих отладчик Visual Basic намного проще, чем отладчик Visual C++. Он также включает несколько превосходных поддерживающих окон, которые делают отладку довольно простым занятием. В этом разделе рассмотрены три окна VB-отладчика: Locals, Immediate и Watch.
Окно Immediate
По моему мнению, окно Immediate Visual Basic изумительно. Хотелось бы, чтобы все отладчики имели такие развитые встроенные возможности отладки. Окно Immediate поддерживает подчиненную отладку и, по существу, является мини-интерпретатором Basic, позволяя выполнять фрагменты кода.
Окно Immediate показывает вывод трассы операторов Debug.Print. Имейте в виду, однако, что это окно обеспечивает отображение лишь 200 строк, поэтому может потребоваться прокрутить строки трассировки (по экрану), для того чтобы прочитать их. К сожалению, нельзя очистить окно Immediate программным способом, чтобы гарантировать просмотр важных операторов трассировки. Надеемся, что в следующей версии Visual Basic будет предложен метод Debug, clear.
Главное преимущество окна Immediate состоит в том, что в нем можно изменять значения переменных и вызывать подпрограммы прямо в приложении. Чтобы увидеть значение конкретной переменной программы, скажем, frmFoo.x, нужно использовать символ ? или оператор Print (т. е. для вывода значения нужно напечатать: ? FrmFoo.x). Прелесть окна Immediate в том, что в него встроены все замечательные IntelliSense-функции Microsoft. Например, если ввести правильное имя объекта, то IntelliSense покажет на экране методы и свойства этого объекта.
Технология IntelliSense известна также под названием Automatic Statement Completion (автоматическое завершение операторов). — Пер.
Для того чтобы изменить значение переменной, просто напечатайте строку кода Visual Basic в окне Immediate — точно так же, как если бы требовалось присвоить значение этой переменной в окне исходного кода. Окно Immediate "знает" все о свойствах "только-для-чтения" (read-only) и синтаксисе языка и известит вас через панель сообщения о том, что какое-либо действие окончилось неудачей.
Один удачный прием, доступный в окне Immediate, позволяет создать приспособление для быстрого тестирования. Например, если вы разрабатываете класс, то можете протестировать его в окне Immediate сразу же, как только напечатаете его код в исходном редакторе.
Если этот класс имеет имя clcMyclass и содержит метод с именем DoSomethingMagical, то можете ввести (строка за строкой) в окно Watch следующий код:
Set x = New clsMyClass
х.DoSomethingMagicai
Set x = Nothing
и протестировать данный метод. Убедитесь, что восстанавливаете в объектных переменных значение Nothing, чтобы не оставить в окне Immediate инициализированные переменные активными. Если установить точки прерывания в методе DoSomethingMagicai, то можно будет выполнять его пошаговый проход.
Кроме того, окно Immediate поддерживает вызов специальных отладочных функций. Вспомнив правила для ограничений на вызов отладочных функций из окна Watch Visual C++ (см. раздел "Вызов функций в окне Watch" главы 5), вы высоко оцените простоту использования окна Immediate. Единственное ограничение на вызов функций в окне Immediate — функция должна существовать в программе. Трудно сказать, какое свойство интенсивной отладки использовать легче.
Хотя окно Immediate позволяет "одним махом перепрыгнуть небоскреб", оно не позволяет писать полноценное приложение. Первое ограничение: в окне Immediate нельзя писать функции. Второе: окно Immediate выполняет за один раз только одну строку кода. Некоторые структуры управления, такие как циклы For...Next, требуют записи нескольких операторов. Для этого предназначена специальная операция ":", позволяющая располагать операторы в одной строке. Ниже приведен пример записи цикла For.. .Next в окне Immediate:
For i = 1 to UBound(a) : ? a(i) :'Next i
Окно Locals
Окно Locals довольно простое, тем не менее обращу внимание читателя на три ключевых момента. Во-первых, в отличие от окна Watch отладчика Visual C++, окно Locals в Visual Basic не требует, чтобы программист тратил силы на приведение типов и прочие хитрости, чтобы значения отображались в соответствующем формате. Во-вторых, наиболее важная переменная, показанная в окне Locals, является Me-объектом. Подобно указателю this языка C++, Me-объект является родовой конструкцией, которая полностью описывает текущий объект и его свойства.
И, наконец, последнее: иногда можно изменять локальные переменные в этом окне, выбрав переменную и щелкнув (кнопкой мыши, конечно) на поле Value. Если Visual Basic позволит изменять переменные, то в поле Value будет разрешено редактирование текста. Visual Basic не позволяет изменять объекты и некоторые переменные типа variant. Например, нельзя изменять какое-либо из свойств элементов управления в коллекциях форм Controls. Однако если в форме имеются переменные с действующими типами элементов управления, такими как CommandButton, то изменение свойств этих элементов через переменные допустимо. В тех случаях, когда нельзя изменять значение переменной в окне Locals, можно воспользоваться окном Immediate.
Для того чтобы редактировать результат буксировки в окне Watch, просто выполните щелчок правой кнопкой мыши в окне Watch и выберите команду Edit Watch всплывающего (контекстного) меню.
Прежде чем переходить к следующему разделу, упомянем еще два аспекта окна Watch. Первый — можно редактировать значения щелчком мыши на поле Value. Так же, как и в окне Locals, если IDE Visual Basic разрешает редактирование, то вы можете изменять значения. Выражения можно также редактировать прямо по месту.
Мне еще нравится помещать в окно Watch специальные значения, такие, например, как Err.Description. Это позволяет следить за любыми ошибочными значениями, с которыми можно столкнуться, если "перешагивать" через функции. Если отлаживаемое приложение получает также параметры из командной строки, я помещаю в окно Watch значение command, чтобы получить возможность быстро проверять различные параметры командной строки, которые приложение могло бы использовать (без необходимости их предварительной установки на вкладке Make диалогового окна Project Properties). К сожалению, как было сказано в начале данной главы, невероятно раздражающее свойство среды VB IDE заключается в том, что она "забывает" все тщательно построенные наблюдения и точки прерывания, как только вы ее покидаете (так что приходится повторно вводить их, начиная каждый новый сеанс отладки).
Отключите режим Compile On Demand
VB IDE пытается сделать отладку быстрее, компилируя только часть приложения, достаточную для передачи в отладчик. Хотя идея выглядит нормально, проблема состоит в том, что в ходе отладки приложения можно "нарваться" на секцию кода, которая не была откомпилирована, и сеанс отладки будет неожиданно остановлен с сообщением о синтаксической ошибке. К тому же, это может произойти в тот момент, когда та единственная ошибка, которая сводила вас с ума, уже почти дублирована. Согласитесь, это будет неприятно.
Для того чтобы избежать каких-либо синтаксических сюрпризов, начинайте сеанс отладки командой Start With Fall Compile, Я даже добавил кнопку этой команды в панель инструментов Debug. Также выключайте режим Compile On Demand на вкладке General диалогового окна Options. Если вы работаете с большим приложением, то это увеличит время начального запуска отладки, но, по крайней мере, застрахует от обнаружения синтаксической ошибки в середине сеанса отладки.
Отладка и реальность
Как было сказано выше (в разделе "Р-код Visual Basic" этой главы), Visual Basic может отлаживать объекты только на уровне интерпретируемого р-ко-да. В современном мире СОМ+-технологий и компонентных служб (Component Services) можно выполнять отладку объектов с помощью отладчика Visual Basic, но большая часть документации содержит настойчивые рекомендации выполнять отладку объектов Visual Basic на компилируемом уровне средствами отладчика Visual C++.
Для приложений компонентных служб1 я следовал рекомендациям, перечисленным в файле READMEVB.HTM системы Visual Basic 6, установленной как часть Visual Studio. Раздел "Building and Debugging MTS Components in Visual Basic 6" (Построение и отладка МТ82-компонентов в Visual Basic 6) этого документа точно сообщает, что нужно делать, чтобы отладить приложения. Сведения об отладке приложений СОМ+ можно найти в MSDN в следующих темах из Platform SDK: "Debugging Components Written in Visual Basic" (Отладка компонентов, написанных на Visual Basic) и "СОМ+ Visual Basic Debugging Support Contrasted with MTS" (Поддержка Visual Basic-отладки компонентов COM+ в сопоставлении с компонентами MTS).
Приложения компонентных служб (от англ. Component Services applications). — Пер.
MTS — Microsoft Transaction Server. — Пер.
Чтобы полностью отладить какую-нибудь компонентную службу или СОМ-объекты, я просто компилирую объекты и использую либо отладчик SoftICE, либо отладчик Visual C++. Отладка компилируемого кода Visual Basic нелегка, но задачу можно упростить, увеличив количество операторов трассировки, для того чтобы просматривать все переменные и другую необходимую информацию. Итак, лучше все-таки отлаживать компонентные службы и приложения СОМ+ как компилируемые приложения (вместо работы в условиях ограничений VB-отладчика).
Перехват ошибок: режимы Break In или Break On
Теперь вернемся к режимам перехвата различных ошибок. VB IDE может выполняться в трех режимах: режиме проектирования (когда выполняется кодирование), режиме выполнения (когда приложение выполняется под отладчиком) и режиме прерывания (когда приложение останавливается отладчиком).
Когда приложение наталкивается на позиционную точку прерывания, IDE автоматически переходит в режим прерывания. Однако, когда приложение генерирует ошибку, IDE перейдет (или не перейдет) в режим прерывания, в зависимости от установки трех следующих режимов:
Break On All Errors (Прерывать на всех ошибках); Break On Unhandled Errors (Прерывать на необработанных ошибках); Break In Class Module (Прерывать в модуле класса).Когда я только начинал программировать на Visual Basic, то долго не мог получить класс, выдававший такую ошибку времени выполнения, которая обрабатывалась бы в режиме прерывания. После изрядных мучений, наконец, было найдено "секретное" меню, которое позволяло устанавливать эти режимы отлавливания ошибок.
Режим перехвата ошибок можно устанавливать на вкладке General диалогового окна Option (открываемого командой Tools|Options). По умолчанию Visual Basic устанавливает режим Break In Class Module. Можно также изменять режим перехвата ошибок "на лету". Для этого нужно открыть (правым щелчком мыши в исходном окне) контекстное меню, выделить пункт Toggle и в раскрывшемся подменю включить нужный режим перехвата ошибок.
Последствия работы с отладчиком
Напомню, что в разделе "MinDBG: простой отладчик для Win32" главы 4, рассказано о том, насколько более устойчива отладка в 32-разрядных верcиях Windows, по сравнению с 16-разрядными, потому что в первом случае подчиненный отладчик находится вне адресного пространства основного отладчика. VB-отладчик понимает только интерпретируемый р-код, поэтому в результате подчиненный VB-отладчик выполняется в том же самом адресном пространстве, что и основной. Большинству разработчиков на Visual ) Basic известно, что VB не присущи проблемы, аналогичные тем, которые \ порождает применение указателей в С-программах, но ошибочный компо нент, загружаемый приложением VB, может привести к аварийному завершению VB IDE и потере части проекта.
Следующие три конкретных правила должны помочь читателю разумно использовать VB-отладчик:
будьте крайне осторожны при подклассификации или использовании операции AddressOf; в общем случае, во время отладки считайте, что исходный код имеет атрибут "только-для-чтения" (read-only); при отладке не пользуйтесь остальной частью IDE.Подклассификация (subclassing) в программировании для Windows — это метод, позволяющий приложению перехватывать и обрабатывать сообщения, посланные некоторому окну, прежде чем оно сможет обработать его. — Пер.
Будьте крайне осторожны при подклассификации или использовании оператора AddressOf
Большинство VB-приложений прекрасно выполняются под отладчиком. Однако если приложение подклассифицирует элементы управления Windows или вы используете операцию AddressOf, чтобы переслать одну из ваших подпрограмм как перехватчик обратных вызовов или процедуру таймера, то следует соблюдать особую осторожность, потому что приложение выполняется в том же самом адресном пространстве, что и VB-отладчик. Отлаживая приложение, необходимо учитывать, что обратные вызовы и таймеры могут все еще выполняться после того, как приложение будет остановлено, в результате приводя к аварийному завершению IDE.
Если выполняется подклассификация оконной процедуры в режиме перерывания внутри VB-отладчика, то после получения сообщения окном, которое вы подклассифицировали, IDE завершится аварийно. К счастью, из-за того что подклассификация окон — такая общая операция, Microsoft обеспечивает решение с помощью утилиты DBGWPROC.DLL. Эта DLL позволяет подклассифицировать окна во время работы с VB-отладчиком. DBGWPROC.DLL можно найти по адресу http://msdn.microsoft.com/vbasic /downloads/controls.asp.
Если оператор AddressOf используется для передачи одной из подпрограмм приложения функциям обработки прерываний, обратных вызовов или таймера операционной системы, то никакой помощи, подобной DBGWPROC.DLL, ждать не приходится. При желании, конечно, можно запустить приложение под VB-отладчиком. Однако всегда следует выполнять приложение (до завершения) таким образом, чтобы любые обработчики прерываний и обратные вызовы не выполнялись. Если для остановки приложения используется команда End меню Run или комбинация клавиш <Ctrl>+<Break>, то могут возникнуть ситуации, в которых ваша процедура не находится больше в памяти, поэтому IDE завершится аварийно.
Для обхода проблемы, связанной с AddressOf, можно рекомендовать другую методику, которая включает специальную отладочную функцию, чистящую любые обработчики прерываний, обратные вызовы и таймеры, и которую можно вызывать либо специальной кнопкой в приложении, либо через окно Immediate. При наличии такой функции уменьшается вероятность ошибочных обращений к приложению, которые могли бы вызвать аварийный останов IDE.
В общем случае, во время отладки считайте, что исходный код имеет атрибут "только-для-чтения" (read-only)
VB IDE настроена так, чтобы облегчать редактирование исходного кода и не останавливать выполнение во время сеансов отладки. Многие разработчики чувствуют, что эта возможность — одно из лучших свойств отладчика. Однако пользоваться им нужно с предельной осторожностью.
Чтобы автоматически сохранять все исходные файлы при запуске приложения в отладчике, нужно установить специальный режим VB IDE — Save Changes.
Для этого следует установить флажок Save Changes на вкладке Environment диалогового окна Options. Если исходный код исправляется "на лету" (on the fly), то рекомендуется сохранять изменения как можно чаще (на случай, если VB-отладчик завершится аварийно). Лично я не делаю каких-либо изменений во время выполнения приложения в отладчике и никому не советую. Я полагаю, что, находясь в отладчике, нужно выполнять отладку, а не редактирование. Ведь добавить ошибку во время редактирования легче, чем устранить ее в ходе кропотливой отладки.
При отладке не пользуйтесь остальной частью IDE
Поскольку всю работу по управлению приложением во время отладки выполняет IDE, то могут возникнуть некоторые проблемы, если попытаться в IDE получить доступ к свойствам приложения, не связанным с отладкой. Например, если приложение использует уведомления таймера для фоновой обработки, и вы раскроете какое-нибудь модальное окно, скажем диалоговое окно Open Project или Options, то таймерная процедура приложения может перестать получать сообщения таймера.
При работе в VB-отладчике рекомендуется использовать его отладочные окна. Если в приложении есть специализированный код (таймеры или немодальные диалоговые окна), то любое дополнительное взаимодействие с IDE может привести к тому, что приложение будет получать сообщения, которые не являются нормальной частью прикладного процесса. Вследствие того, что окна приложения являются частью той же самой очереди поточных сообщений, что и от IDE, в некоторых случаях работа отладчика будет затруднена из-за тесного взаимодействия между основным и подчиненным отладчиком. Наихудший случай — необходимость отладки сообщений нажатия клавиш мыши или клавиатуры. В этих ситуациях для отладки кода можно использовать только операторы Debug. Print.
Р-код Visual Basic
Опытные разработчики знают все о р-коде языка Visual Basic (VB), но необходимо, чтобы каждый читатель совершенно точно понимал, что происходит, когда выполняется VB-приложение, и представлял себе последствия отладки VB-приложений. Наряду с другими аспектами отладки, понимание работы отладчика может чрезвычайно помочь в этом. Для того чтобы установить систему определенных понятий, начнем с небольшого урока истории.
Режим Break In Class Module
Этот режим предназначен для отладки СОМ-серверов. Выбирая этот режим перехвата ошибок, вы сообщаете отладчику, что хотите рассматривать все ошибки в модулях классов так, как если бы не было никаких обработчиков ошибок. Хотя режим Break In Class Modules позволяет получать ошибки от СОМ-серверов, пользовательские обработчики ошибок игнорируются по-прежнему.
Режим Break On All Errors
Как подсказывает само название режима (прерывать на всех ошибках), всякий раз, когда VB-отладчик сталкивается с ошибкой времени выполнения, он останавливается и открывает диалоговое окно, показанное на рис. 7.1. Прерывание будет вызывать любая ошибка, даже если в программе имеется обработчик ошибок. Вообще говоря, этот режим перехвата ошибок не так полезен и я использую его, только если мне нужно увидеть, где возникла конкретная ошибка и когда она происходит в функции (не обращая внимания ни на какие обработчики ошибок).
По существу, при установке режима перехвата ошибок Break On All Errors выключаются все обработчики ошибок, встроенные в отлаживаемое приложение. Выполнение прерванного на ошибке приложения может быть продолжено путем перетаскивания стрелочного указателя с текущей выполняемой строки (на которой возникла ошибка) к следующей за ней выполнимой строке или с помощью команды Set Next Statement контекстного меню. Единственная проблема, возникающая в результате изменения строки выполнения, состоит в том, что Visual Basic не будет передавать вам фактическую ошибку для обработки.
Режим Break On Unhandled Errors
Судя по названию, режим Break On Unhandled Errors вынудит отладчик перейти в режим прерывания, если возникла ошибка, а обработчика для нее в программе нет. Этот режим прекрасно работает почти во всех ситуациях и я установил его в качестве режима перехвата ошибок по умолчанию. К сожалению, если отлаживаются системы СОМ-серверов (как внутриза-дачных (in-process), так и внезадачных (out-of-process)), то прерывания на ошибках модулей классов выполняться не будут. При отладке таких систем поступают иначе: возникшие ошибки упаковываются и передаются обратно клиенту как нормальные СОМ-ошибки. Для того чтобы выполнить прерывание в СОМ-серверах, нужно установить режим перехвата ошибок Break In Class Modules.
В этой главе представлен краткий
В этой главе представлен краткий обзор различных свойств и проблем, относящихся к отладчику Visual Basic. Понимая ограничения отладочной среды Visual Basic и, прежде всего, тот факт, что отладчик воспринимает только интерпретируемый р-код и выполняет подчиненный отладчик внутри того же самого адресного пространства, программист может лучше приспосабливаться к этим требованиям. Чтобы надлежащим образом отлаживать возникающие ошибки, следует установить специальный режим перехвата ошибок (его выбор зависит от того, что вы собираетесь отлаживать). Наиболее полезными частями отладчика являются окна Immediate и Watch. Если приложение может быть полностью отлажено только средствами отладчика Visual Basic, то необходимо ознакомиться с этими окнами, потому что они позволяют значительно ускорить отладку.
Как видите, отладчик Visual Basic довольно противоречив; некоторые части отладчика чрезвычайно помогают программисту, тогда как другие являются источниками довольно серьезных проблем. Visual Basic дал возможность разрабатывать Windows-приложения быстрее, чем когда-либо прежде. К сожалению, слабости VB-отладчика пока довольно существенны.
Как обычно, закончим главу некоторыми
Как обычно, закончим главу некоторыми советами и особыми приемами, которые призваны облегчить жизнь разработчика, отлаживающего программу.
истории р-кода
Visual Basic 1, представленный в 1991 году, был многообещающим прогрессом в средствах программирования. В начале 90-х, разработки для Microsoft Windows необходимо было писать на языке С средствами SDK, что было, вообще говоря, довольно сложно и требовало больших усилий. Visual Basic обещал и, в большинстве случаев, предоставлял возможность "рисовать" интерфейс пользователя (UI) при помощи инструмента, получившего название WYSIWYG (What-You-See-Is-What-You-Get — "что -вы -видите, то -вы -и получаете"), и легкий способ связывать код с событиями пользователя, такими как щелчок кнопкой мыши. Необычным свойством в Visual Basic I было то, что он компилировал окончательное приложение не в "родной" выполняемый код, а в форму, называемую р-кодом.
Термин р-код (p-code — сокращение от packed code, переводится как "упакованный код") происходит от названия метода сокращения объема памяти для хранения двоичных файлов (размер р-кода намного меньше, чем код языка ассемблера для процессоров Intel x86). При "компиляции" приложения в Visual Basic 1 создается регулярный выполняемый код, но это только оболочка для р-кода. Когда запускается "компилированный" двоичный файл (с этого начинается так называемое "время выполнения" (run-time) программы), по определенному смещению в памяти отыскивается р-код и начинается его выполнение. Известно, что вместе с приложением должна быть загружена большая библиотека динамической компоновки (DLL) VBRUN100.DLL, которая содержит интерпретатор р-кода.
DLL иногда называют также библиотеками времени выполнения (run-time library). — Пер.
Интерпретатор р-кода — стековая машина, которая транслирует специальные коды операций в операции CPU. Во времена MS-DOS и 16-разрядных Windows компания Microsoft предлагала иную форму р-кода, генерировавшуюся в системах программирования C/C++ 7.x. В действительности, первоначальные 16-разрядные версии продуктов Microsoft Word, Excel и PowerPoint широко использовали р-код этой системы в своих UI-кодах, чтобы достичь компромисса "размер памяти/производительность" и обеспечить выполнение этих приложений в операционных системах с ограниченной памятью (например, выпускавшихся тогда Windows 3 и 3.1).
С идеей реализации р-кода в системах C/C++ 7.x, которая, вероятно, близка к реализации р-кода в Visual Basic, можно ознакомиться в библиотеке MSDN, найдя тему "Microsoft P-Code Technology" (Технология р-кода компании Microsoft).
Все версии Visual Basic от 1-й до 4-й генерировали только р-код. Самая большая проблема в его применении состояла в том, что он был медленнее, чем исполняемый двоичный. Старая шутка гласила, что вы общались с Visual Basic на расстоянии в целую милю (потому что приложение работало очень медленно, т. к. использовало трехмерные элементы управления для всех текстовых кнопок). Компания Microsoft никак не могла повлиять на выбор разработчиками элементов управления, но учла просьбу "номер один" разработчиков Visual Basic, требовавших возможности компилировать исполняемые файлы.
Начиная с Visual Basic 5, выпущенного в 1997 году, компания Microsoft добавила специальный режим, который поддерживал такую компиляцию. Разработчики Microsoft также переписали исполнительную (run-time) систему Visual Basic, сделав ее быстрее. Результатом обоих изменений было фантастическое повышение производительности приложений Visual Basic. Единственный недостаток заключался в том, что Microsoft сделала лишь точечную прививку свойства родной компиляции к дереву свойств системы Visual Basic, а не полностью интегрировала компиляцию и отладку со средой VB IDE. После компиляции приложения в исполняемый код программисту предоставлялась "полная свобода" в его отладке. Поскольку двоичные файлы Visual Basic не имеют достаточного количества отладочных символов, что обсуждалось в разделе "Отладка компилированного кода Visual Basic" главы 5, разработчик почти вынужден отлаживать программу на необработанном языке ассемблера.
Самый большой недостаток компиляции в исполняемый код заключается в том, что VB IDE понимает только интерпретируемый р-код. Таким образом, VB-отладчик имеет дело с р-кодом, а это совсем не то, что получается в результате — исполняемый компилированный код.С точки зрения отладки и тестирования ситуация неприятная, — даже отдавая предпочтение компиляции в двоичный р-код, вы не отлаживаете точно те биты, которые посылаете заказчикам. К сожалению, ничего не остается, как мучиться с отладкой компилируемого двоичного VB-файла под отладчиком Visual C++. Остается надеяться, что в будущей версии Visual Basic или Microsoft Visual Studio эта проблема будет исправлена, и приложения, отлаженные разработчиками, будут точно соответствовать тому, что получат заказчики.
Заключительные предложения по перехвату ошибок
Как можно понять из этого обсуждения, перехват ошибок в VB-отладчике вряд ли желателен. Если вы хотите останавливаться на ошибках, то вы можете это делать, но за счет способности "переступать" через обработчики ошибок. Единственный реальный обходной путь состоит в том, чтобы устанавливать точки прерывания на всех обработчиках ошибок, которые требуется выполнить в пошаговом режиме, и задать режим перехвата ошибок Break On Unhandled Errors. В чем мы действительно нуждаемся, так это в способе останавливать выполнение при возникновении ошибок, но обрабатывать их при помощи нормальных приемов.
Остается только надеяться, что команда VB-разработчиков сжалится над теми, кто хочет отлаживать свои приложения полностью и предложит для этого удобные, эффективные инструменты. Искусственные ограничения, наложенные на перехват ошибок в VB-отладчике, серьезно затрудняют отладку приложений.
Поскольку проблемы перехвата ошибок связаны непосредственно с конструкциями On Error GOTO в языке Visual Basic, следует обратить особое внимание на использование обработчиков ошибок в программах. Следующий раздел этой главы я собирался посвятить надлежащей обработке ошибок, но Пит Моррис (Peet Morris) сообщил, что соответствующую тему он обсуждает в главе 1 (названной так: "On Error GoTo Hell") книги Advanced Microsoft Visual Basic 6.0, The Mandelbrot Set, 2nd ed., Microsoft Press, 1998. Если вы даже только раздумываете о разработках на Visual Basic, эту главу нужно прочитать обязательно.
