Как изменить системную форму сообщения об ошибке в 1С и настроить отправку отчета разработчику?

← На главную

При возникновении необработанных исключений в пользовательском режиме (например, при делении на ноль или обращении к несуществующему реквизиту) платформа 1С:Предприятие выводит системное модальное окно с описанием проблемы и кнопками «Завершить работу», «Перезапустить» или «Подробно». У разработчиков часто возникает задача модифицировать этот диалог — например, добавить кнопку «Отправить ошибку разработчику», чтобы пользователь в один клик мог передать диагностические данные. Рассмотрим, возможно ли изменить эту форму и какие существуют альтернативные способы решения данной задачи.

Архитектурные ограничения платформы 1С

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

Ядро платформы: Стандартное диалоговое окно критической ошибки скомпилировано в исполняемом коде платформы 1С (на языке C++). В дереве метаданных конфигурации нет соответствующего объекта, формы или общего макета, который за него отвечает.
Отсутствие глобального перехватчика: В управляемом приложении 1С не предусмотрено глобального клиентского обработчика необработанных исключений (аналога Application.ThreadException или window.onerror). Если ошибка не была обработана в кодовой конструкции разработчика, управление сразу передается системному диалогу платформы.

Таким образом, внедрить произвольные кнопки или перерисовать стандартный диалог ошибки платформенными средствами невозможно. Разберем рабочие и архитектурно правильные способы сбора сведений об ошибках.

Почему сплошное использование «Попытка — Исключение» — ошибочный путь

Иногда разработчики пытаются решить задачу тотальным оборачиванием кода в блоки перехвата:


Попытка
    // Потенциально опасный код
    Результат = Значение1 / Значение2;
Исключение
    // Вызов своей формы или отправка письма
    ПоказатьПредупреждение(, "Произошла ошибка: " + ОписаниеОшибки());
КонецПопытки;

Такой подход имеет серьезные архитектурные недостатки:

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

Конструкцию Попытка ... Исключение следует применять строго точечно (например, при интеграциях, обращении к внешним веб-сервисам, парсинге файлов или работе с COM-объектами), а общую диагностику строить на специализированных механизмах.

Решение 1. Использование встроенных подсистем БСП

Если конфигурация создана на базе Библиотеки стандартных подсистем (БСП), в ней уже присутствуют готовые инструменты для решения этой задачи:

Подсистема «Центр мониторинга»: Позволяет настроить сбор аварийных дампов и информации об ошибках с автоматической передачей на произвольный HTTP-сервис вашей компании или службы сопровождения.
Подсистема отправки сообщений в службу техподдержки: Предоставляет пользователю стандартизированную форму обращения (через главное меню программы). Механизм автоматически прикрепляет к письму или веб-запросу скриншот экрана, сведения о версии конфигурации, операционной системе, релизе платформы, правах доступа и последние записи системного журнала.

Решение 2. Фоновый сбор ошибок из Журнала регистрации

Все системные необработанные исключения пользователей автоматически фиксируются в Журнале регистрации с уровнем важности УровеньЖурналаРегистрации.Ошибка. Мы можем настроить регламентное задание, которое будет регулярно опрашивать журнал и отправлять отчеты разработчикам.

Рассмотрим пример программного кода для процедуры регламентного задания, собирающего свежие ошибки:


Процедура ОтправитьОшибкиРазработчику() Экспорт

    ПериодПроверки = ТекущаяДатаСеанса() - 300; // Проверяем за последние 5 минут
    
    Отбор = Новый Структура;
    Отбор.Вставить("ДатаНачала", ПериодПроверки);
    Отбор.Вставить("Уровень", УровеньЖурналаРегистрации.Ошибка);
    
    ТаблицаОшибок = Новый ТаблицаЗначений;
    ВыгрузитьЖурналРегистрации(ТаблицаОшибок, Отбор, "Дата, Пользователь, ИмяПользователя, Событие, ПредставлениеСобытия, ОписаниеВобытия, Метаданные, Данные");
    
    Если ТаблицаОшибок.Количество() = 0 Тогда
        Возврат;
    КонецЕсли;
    
    ТекстСообщения = "";
    Для Каждого СтрокаОшибки Из ТаблицаОшибок Цикл
        ТекстСообщения = ТекстСообщения + "=== Ошибка от " + Строка(СтрокаОшибки.Дата) + " ===" + Символы.ПС;
        ТекстСообщения = ТекстСообщения + "Пользователь: " + СтрокаОшибки.ИмяПользователя + Символы.ПС;
        ТекстСообщения = ТекстСообщения + "Событие: " + СтрокаОшибки.ПредставлениеСобытия + Символы.ПС;
        ТекстСообщения = ТекстСообщения + "Описание: " + СтрокаОшибки.ОписаниеВобытия + Символы.ПС + Символы.ПС;
    КонецЦикла;
    
    // Отправка сформированного текста (через ИнтернетПочта, HTTP-запрос в мессенджер или таск-трекер)
    ОтправитьУведомлениеРазработчикам(ТекстСообщения);

КонецПроцедуры

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

Решение 3. Мониторинг через Технологический журнал и внешние системы

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

Настройка технологического журнала (logcfg.xml): Позволяет настроить сбор событий EXCP (исключительные ситуации) и EXCPCNTX (контекст исключений) на уровне сервера приложений 1С.
Интеграция с внешними системами мониторинга (ELK Stack, Sentry, Vector): Логи сервера и технологического журнала в реальном времени передаются в централизованную систему, где ошибки группируются по типам, а ответственные специалисты получают мгновенные алерты с полным контекстом сбоя.