В процессе разработки в конфигураторе 1С каждый программист сталкивается с ситуацией, когда при сохранении изменений система выдает список синтаксических ошибок. Однако иногда, после того как мы один раз «проигнорировали» эти ошибки (нажали «Да» в окне с вопросом «Продолжить?»), автоматические уведомления пропадают. Это создает ложное ощущение корректности кода, хотя ошибки никуда не делись. В рамках данной статьи мы подробно разберем, почему конфигуратор ведет себя именно так, и изучим механизмы, которые позволят нам восстановить полный контроль над качеством программного кода.
Первым делом выясним причину, по которой ошибки перестают «выскакивать» автоматически. В платформе 1С реализован механизм оптимизации: конфигуратор проверяет на ошибки не всю базу целиком при каждом нажатии кнопки Сохранить, а только те объекты, которые были изменены.
Когда вы вносите изменения в текст модуля, рядом с его названием в дереве конфигурации появляется «звездочка» (*). Это признак того, что объект модифицирован. Если при попытке сохранения или обновления конфигурации базы данных (клавиша F7) система обнаруживает ошибки, она выводит предупреждение. Нажав кнопку «Да» (продолжить, несмотря на ошибки), вы даете платформе команду принять этот текст «как есть».
В этот момент происходит следующее:
Следовательно, при следующем сохранении всей конфигурации система просто пропускает этот модуль, так как в нем (с точки зрения метаданных) ничего не менялось с момента последней записи. Чтобы снова увидеть ошибку при обычном сохранении, нам придется внести в модуль любое изменение (например, поставить и удалить пробел), чтобы флаг модифицированности снова стал активным.
Рассмотрим ситуацию, когда модулей много, и мы не знаем точно, где именно остались неисправленные ошибки. В этом случае обычная кнопка «Проверка модуля» (синяя галочка на панели инструментов) нам не поможет, так как она анализирует только текущее открытое окно.
Для комплексного анализа нам необходимо запустить процедуру «Проверка конфигурации». Проанализируем, как это сделать правильно:
Тонкий клиент, Сервер, Внешнее соединение и т.д. Часто ошибка «Тип не определен» возникает именно из-за того, что мы пытаемся вызвать серверный метод или тип данных в контексте клиента.После завершения этого процесса в окне «Служебные сообщения» появится полный список всех проблемных мест во всей конфигурации. Это самый надежный способ «выловить» все забытые ошибки после того, как они были однажды проигнорированы.
Выясним, не сбились ли настройки самого конфигуратора, которые отвечают за вывод сообщений об ошибках. Иногда отсутствие уведомлений связано с тем, что в параметрах отключены соответствующие опции. Разберем по шагам, где найти эти настройки:
Рассмотрим специфическую ошибку, упомянутую в вопросе: {ОбщийМодуль.ИмяМодуля(1,1)}: Тип не определен (метод). Если ошибка указывает на первую строку модуля (1,1), это часто свидетельствует о проблемах с директивами компиляции или свойствами общего модуля.
Проанализируем свойства вашего общего модуля в палитре свойств:
Клиент (управляемое приложение), но нет галочки Сервер, то при использовании типов данных, доступных только на сервере (например, Запрос или СправочникОбъект), система выдаст ошибку.Экспорт и он доступен в текущем контексте (клиентском или серверном).Для исправления подобных ситуаций мы рекомендуем использовать инструкции препроцессора, чтобы разделять код для разных сред исполнения:
#Если Сервер Тогда
// Этот код будет виден только на сервере
Процедура ОбработатьДанныеНаСервере() Экспорт
Запрос = Новый Запрос;
// ... работа с запросом
КонецПроцедуры
#КонецЕсли
Если все настройки верны, проверка конфигурации запускается, но сообщения всё равно не выводятся (хотя вы точно знаете, что в коде есть ошибка), мы можем столкнуться с проблемой «зависания» локального кэша. Платформа 1С сохраняет промежуточные результаты компиляции в локальных папках пользователя. Если кэш поврежден, конфигуратор может «думать», что модуль корректен, основываясь на старых данных.
Чтобы исключить этот фактор, выполним следующие действия:
%AppData%\1C\1Cv8\ и %LocalAppData%\1C\1Cv8\.После этой процедуры при первом открытии конфигуратор заново проанализирует весь код, и механизм автоматического обнаружения ошибок вернется в исходное состояние.
Подводя итог, можно сказать, что «исчезновение» ошибок — это штатное поведение платформы, связанное с оптимизацией процесса разработки. Чтобы всегда держать код под контролем, возьмите за правило:
Соблюдение этих простых правил позволит вам избежать накопления скрытых ошибок, которые могут проявиться в самый неподходящий момент при работе пользователей.