В практике программирования на различных языках часто возникает необходимость принудительно передать управление отладчику из самой программы. В JavaScript для этого используется команда debugger, в Python — breakpoint(), а в низкоуровневом ассемблере — прерывание int 3. В платформе 1С:Предприятие штатной команды с подобным функционалом на текущий момент не существует. Это создает определенные трудности при работе со сложными механизмами: правилами обмена данными, динамически формируемым кодом (Выполнить, Вычислить) или внешними печатными формами (ВПФ), которые сохраняются во временные файлы.
В данной статье мы подробно рассмотрим, как можно имитировать поведение программной точки останова, разберем существующие инструменты платформы и выясним, какие методы наиболее эффективны для отладки «невидимого» кода.
Проанализируем самый популярный среди разработчиков 1С «костыль», который позволяет заставить конфигуратор остановиться в нужном месте кода. Суть метода заключается в использовании настройки отладчика «Остановка по ошибке». Разберем этот алгоритм по шагам:
Рассмотрим пример реализации такого блока:
Попытка
// Искусственная ошибка: деление на ноль
А = 1 / 0;
Исключение
// Пустой блок или запись в лог
КонецПопытки;
Выясним, почему это работает. Когда платформа встречает деление на ноль, она генерирует исключение. Если в отладчике включена опция остановки по ошибке, выполнение прервется именно на строке А = 1 / 0;. Мы окажемся внутри контекста выполнения, сможем просмотреть значения переменных в табло и стек вызовов. Важный нюанс: этот метод особенно полезен при отладке кода, который выполняется во временных файлах (например, внешние обработки БСП), так как отладчик автоматически откроет временный файл с исходным кодом.
Если нам нужно иметь возможность гибко включать и выключать точки останова без постоянного редактирования кода в конфигураторе (особенно в условиях, когда конфигурация находится на поддержке), мы можем применить метод «Стоп-флага». Проанализируем, как это реализовать структурно.
Создадим условие, внутри которого поставим обычную точку останова (клавиша F9). Условие должно зависеть от значения, которое мы можем легко изменить в режиме «1С:Предприятие».
Если ПараметрыСеанса.РежимОтладкиВключен Тогда
// Поставьте точку останова (F9) на следующей строке
ТекстСообщения = "Точка остановки достигнута";
КонецЕсли;
Преимущество этого метода в том, что точка останова будет срабатывать только тогда, когда вы активируете соответствующий флаг (например, в константе или параметре сеанса). Это позволяет оставлять отладочный код в рабочей базе, не боясь, что обычные пользователи будут внезапно «вылетать» в конфигуратор.
Рассмотрим стандартный функционал платформы 1С, который часто недооценивают. Платформа позволяет задавать условия непосредственно для точки останова, не меняя сам программный код. Это ближе всего к идее динамического управления отладкой.
Как это сделать:
Объект.Сумма > 100000 или ТекущийПользователь() = Справочники.Пользователи.НайтиПоНаименованию("Администратор").Посмотрим на ситуацию шире: условные точки останова отлично подходят для циклов, когда нам нужно поймать конкретную итерацию, не прокликивая сотни раз кнопку F5.
Проанализируем ситуацию, упомянутую в обсуждении: отладка строк кода, которые передаются в команду Выполнить(). Технически в 1С невозможно поставить точку останова внутри строки текста. Однако, если этот код формируется динамически и записывается во временный файл как внешняя обработка, мы можем применить хитрость с «Остановкой по ошибке», описанную в Методе 1.
В современных конфигурациях на базе БСП (Библиотека стандартных подсистем) для отладки внешних обработок и печатных форм предусмотрены штатные механизмы. Рассмотрим, как упростить этот процесс:
Выясним причину, по которой фирма 1С не спешит внедрять команду ОстановитьОтладку(). Архитектура классического отладчика базируется на жесткой привязке к метаданным конфигурации. В новой среде разработки 1C:EDT (Enterprise Development Tools), основанной на Eclipse, используется протокол Debug Adapter Protocol (DAP). Это дает надежду на то, что в будущем механизмы управления отладкой станут более гибкими и приближенными к стандартам других языков программирования.
Пока же наиболее надежным и универсальным способом остается сочетание условных точек останова и блоков генерации исключений в критических местах программы. Мы рекомендуем всегда предусматривать в сложных алгоритмах обмена данными логирование и «диагностические затычки», которые помогут быстро локализовать проблему без глубокого погружения в отладчик.