Как правильно обрабатывать и пропускать ошибки в коде 1С:Предприятие?

← На главную

В процессе разработки на платформе 1С:Предприятие любой программист сталкивается с ситуацией, когда выполнение кода может прерваться из-за непредвиденной ошибки. Это может быть связано с некорректными данными, отсутствием прав доступа или сбоем внешних сервисов. В этой статье мы подробно разберем, как сделать так, чтобы программа не «вылетала», а корректно обрабатывала проблемные участки кода, и выясним, в каких случаях ошибку стоит «пропустить», а в каких — предотвратить.

Разбираем механизм конструкции Попытка — Исключение

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

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

Проанализируем пример использования этой конструкции для безопасного выполнения кода:


Попытка
    // Пытаемся выполнить опасную операцию
    ОбластьСтрокаПриема.Параметры.ДатаНачалаОкончания = СтрШаблон(ДатаНачалаОкончания, "по настоящее время");
    ДокументРезультат1.Вывести(ОбластьСтрокаПриема);
    ПриемВыведен = Истина;
Исключение
    // Сюда программа попадет только в случае ошибки выше
    ЗаписьЖурналаРегистрации("ОбработкаОшибки", УровеньЖурналаРегистрации.Ошибка, , , ОписаниеОшибки());
    // Здесь мы можем ничего не писать, и тогда ошибка будет просто "пропущена"
КонецПопытки;

Почему просто «пропускать» ошибку — плохая практика?

Многие начинающие разработчики используют пустой блок Исключение, чтобы программа «просто работала дальше». Однако это крайне опасный подход. Если мы просто подавляем ошибку, мы скрываем симптомы проблемы. В будущем это может привести к повреждению данных в информационной базе, которое будет очень сложно отследить. Чтобы выявить такие «тихие» ошибки до того, как они попадут в рабочую базу, можно использовать инструменты для статического анализа кода проектов — есть BSL Language Server для проверки синтаксиса.

Разберем, как правильно вести себя в блоке Исключение. Вместо того чтобы оставлять его пустым, мы рекомендуем анализировать причину сбоя — поможет инструмент пошаговой отладки кода 1С. Для этого в 1С существуют специальные функции:

ОписаниеОшибки(): Возвращает текстовое представление ошибки. Это удобно для вывода сообщения пользователю или записи в лог.
ИнформацияОбОшибке(): Этот метод возвращает объект, содержащий подробные сведения, включая имя модуля и номер строки, где произошел инцидент.

Рассмотрим пример более профессиональной обработки:


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

Превентивные проверки: «Если» вместо «Попытки»

Проанализируем ситуацию, представленную в обсуждении форума. Автор пытается сформировать строку даты и опасается ошибки. Использование исключений для таких целей — это «антипаттерн». Почему? Потому что любая Попытка — это ресурсозатратная операция для сервера. Если вы используете её внутри цикла на 10 000 итераций, скорость работы программы заметно снизится. Для точной оценки влияния таких конструкций на быстродействие системы полезно проводить замеры производительности и поиск узких мест в коде — для этого подойдут инструменты быстрой разработки и оптимизации кода.

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

Посмотрим на пример качественной проверки данных перед выводом:


// Проверяем, заполнена ли переменная и является ли она строкой
Если ЗначениеЗаполнено(ДатаНачалаОкончания) И ТипЗнч(ДатаНачалаОкончания) = Тип("Строка") Тогда
    Попытка
        ОбластьСтрокаПриема.Параметры.ДатаНачалаОкончания = СтрШаблон(ДатаНачалаОкончания, "по настоящее время");
        ДокументРезультат1.Вывести(ОбластьСтрокаПриема);
        ПриемВыведен = Истина;
    Исключение
        // Здесь ловим только действительно непредвиденные сбои (например, проблемы с макетом)
        Сообщить("Критическая ошибка вывода макета: " + ОписаниеОшибки());
    КонецПопытки;
КонецЕсли;

Работа с форматированием дат и строк

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


// Безопасное формирование строки периода
ТекстДаты = "с " + Формат(ДатаНачала, "ДФ=dd.MM.yyyy") + " по " + Формат(ДатаКонца, "ДФ=dd.MM.yyyy");
// Теперь ТекстДаты точно является строкой и не вызовет падения СтрШаблон

Используя метод Формат, мы гарантируем, что даже если дата пустая, мы получим пустую строку или стандартное представление, а не аварийное завершение программы.

Что невозможно «поймать» в блок Попытка?

Важно понимать, что конструкция Попытка — Исключение не является всесильной. Существуют типы ошибок, которые она не сможет обработать:

Ошибки компиляции: Если вы допустили синтаксическую ошибку (например, забыли КонецЕсли), конфигурация просто не запустится, и блок Попытка не поможет. Чтобы избежать подобных проблем на этапе разработки, существуют специальные анализаторы конфигураций на наличие ошибок, которые проверяют код до его запуска.
Критические сбои базы данных: Если произошел физический разрыв связи с SQL-сервером или переполнение диска, 1С может завершить сеанс аварийно, не доходя до блока Исключение.
Административные прерывания: Если администратор принудительно завершил ваш сеанс через консоль кластера, выполнение кода прервется моментально.

Подводим итоги: алгоритм действий программиста

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

Максимально используйте проверки: Проверяйте переменные на Неопределено, используйте ТипЗнч и ЗначениеЗаполнено. Это лучший способ «пропустить» ошибку — просто не дать ей возникнуть.
Используйте Попытку только для внешних факторов: Этот блок идеален для работы с файловой системой, внешними компонентами, COM-объектами или HTTP-запросами, где результат не зависит от вашего кода.
Всегда логируйте исключения: Даже если вы решили не показывать ошибку пользователю, запишите её в ЖурналРегистрации. Это сэкономит вам часы отладки в будущем.
Не злоупотребляйте: Не оборачивайте весь модуль в одну большую Попытку. Оборачивайте только конкретную строку, которая вызывает сомнения.

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