Обработка ошибок в C

Содержание

errno – переменная, хранящая целочисленный код последней ошибки. В каждом потоке существует своя локальная версия errno, чем и обусловливается её безопасность в многопоточной среде. Обычно errno реализуется в виде макроса, разворачивающегося в вызов функции, возвращающей указатель на целочисленный буфер. При запуске программы значение errno равно нулю.

Все коды ошибок имеют положительные значения, и могут использоваться в директивах препроцессора #if. В целях удобства и переносимости заголовочный файл <errno. h> определяет макросы, соответствующие кодам ошибок.

Стандарт ISO C определяет следующие коды:

Нехитрый скрипт печатает в консоль коды ошибок, их символические имена и описания:

Функции работы с errno

Получив код ошибки, хочется сразу получить по нему её описание. К счастью, ISO C предлагает целый набор полезных функций.

<stdio. h>

void perror(const char *s);

<string. h>

strerror() не безопасная функция. Во-первых, возвращаемая ею строка не является константной. При этом она может храниться в статической или в динамической памяти в зависимости от реализации. В первом случае её изменение приведёт к ошибке времени выполнения. Во-вторых, если вы решите сохранить указатель на строку, и после вызовите функцию с новым кодом, все прежние указатели будут указывать уже на новую строку, ибо она использует один буфер для всех строк. В-третьих, её поведение в многопоточной среде не определено в стандарте. Впрочем, в QNX она объявлена как thread safe.

Поэтому в новом стандарте ISO C11 были предложены две очень полезные функции.

size_t strerrorlen_s(errno_t errnum);

errno_t strerror_s(char *buf, rsize_t buflen, errno_t errnum);

Функции входят в Annex K (Bounds-checking interfaces), вызвавший много споров. Он не обязателен к выполнению и целиком не реализован ни в одной из свободных библиотек. Open Watcom C/C++ (Windows), Slibc (GNU libc) и Safe C Library (POSIX), в последней, к сожалению, именно эти две функции не реализованы. Тем не менее, их можно найти в коммерческих средах разработки и системах реального времени, Embarcadero RAD Studio, INtime RTOS, QNX.

Стандарт POSIX.1-2008 определяет следующие функции:

char *strerror_l(int errnum, locale_t locale);

int strerror_r(int errnum, char *buf, size_t buflen);

Увы, никакого аналога strerrorlen_s() в POSIX не определили, поэтому длину строки можно выяснить лишь экспериментальным путём. Обычно 300 символов хватает за глаза. GNU C Library в реализации strerror() использует буфер длиной в 1024 символа. Но мало ли, а вдруг?

Макрос assert()

<assert. h>

Функции atexit(), exit() и abort()

<stdlib. h>

int atexit(void (*func)(void));

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

_Noreturn void exit(int exit_code);

_Noreturn void abort(void);

Функции setjmp() и longjmp()

Вот мы и подошли к самому интересному – функциям нелокальных переходов. setjmp() и longjmp() работают по принципу goto, но в отличие от него позволяют перепрыгивать из одного места в другое в пределах всей программы, а не одной функции.

<setjmp. h>

int setjmp(jmp_buf env);

void longjmp(jmp_buf env, int value);

Используя setjmp() и longjmp () можно реализовать механизм исключений. Во многих языках высокого уровня (например, в Perl) исключения реализованы через них.

Внимание! Функции setjmp() и longjmp () в первую очередь применяются в системном программировании, и их использование в клиентском коде не рекомендуется. Их применение ухудшает читаемость программы и может привести к непредсказуемым ошибкам. Например, что произойдёт, если вы прыгните не вверх по стеку – в вызывающую функцию, а в параллельную, уже завершившую выполнение?

Новое отображение ошибок в 1С

Сегодня давайте рассмотрим развитие механизма отображения ошибок в 1С.

Содержание

Подготовка

Где почитать? ^

Многие после прочтения были воодушевлены. Естественно, ведь наконец-то мы сможем не только работать с этим окном, но и получать от пользователей полноценный отчет об ошибке!

И вот, в версии 8.3.17 мы можем видеть "новое о платформе"

Тем, кому будет интересно самому подробнее погрузиться в этот механизм, можно прочитать на ИТС здесь и здесь

Где и как тестировать? ^

Я выбрал пункт с файлом DT. Вот прямая ссылка на скачивание. Естественно, нужен доступ на users:

Сделаем простую непредвиденную ошибку в коде. Просто попытаемся присвоить в зарезервированную переменную "Неопределено":

Далее будем работать с этой обработкой.

В начале были нюансы. ^

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

Поэтому сразу же для удобства вынесем кнопку "1С:Предприятие", которая будет запускать базу без подключенной отладки.

Теперь запустим в таком режиме сеанс и попробуем выполнить нашу обработку.

Вуаля! Мы видим новое окно с информацией об ошибке! Здесь есть кнопка "Сформировать отчет об ошибке" и нет совершенно упоминание кода, на котором эта ошибка возникла. Но данную форму мы ещё рассмотрим. Давайте закроем сеанс, вернёмся в конфигуратор и запустим 1С в режиме отладки. Теперь, если мы попытаемся выполнить нашу обработку, то увидим старое, уже давно привычное нам, окно с информацией об ошибке:

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

Ещё усугубляет ситуацию то, что часто разработчики советуют пользователям включать этот режим отладки в текущем сеансе. Для того, чтобы появлялась кнопочка "Подробнее. ". Покажу не примере:

Если открыть базу до 8.3.17 (у меня это будет 8.3.15), а далее без режима отладки вызвать ошибку, то мы увидим такое окно:

Что здесь не так? Нет возможности нажать "Подробнее" (чтобы увидеть полный текст ошибки), а так же нет возможности скопировать этот текст.

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

Что видит пользователь? ^

Вернёмся к новому окну.

Вот что пользователь увидит по кнопке "Сформировать отчет об ошибке":

Форма формирования отчета ^

Это новая форма платформы, в которой мы можем внести описание проблемы (например, что мы именно делали перед возникновением ошибки).

Но самое главное, что теперь разработчики могут получить от пользователя автоматически сформированные пункты.

Самое главное, что всё это добро можно сохранить на компьютере в виде архива, а потом переслать кому нужно:

Содержимое отчета об ошибке ^

Давайте посмотрим, что внутри:

Скриншот и файлик JSON. А вот в JSON уже хранится вся информация:

Здесь хранится даже больше, чем нам было показано в окне. Например, вот код локализации:

А вот идентификатор расширений. Их не было на скринах выше:

А здесь вообще подробный стек:

В общем, в JSON хранится много всего интересного. Но рассмотрим его подробнее в следующих статьях. Попытаемся его распарсить.

Как сохраняются скриншоты ^

Перед тем, как перейти далее, рассмотрим то, как 1С создаёт скриншоты окон приложения. Для этого в форме нашей обработки сделаем режим открытия окна "Блокировать весь интерфейс".

И теперь вызовем ошибку.

Как видите, обработка полностью закрыла собой основное окно 1С. Но как будет выглядеть скриншот?

Администрирование ^

Управление настройками обработки ошибок ^

И вот мы видим такую форму. Добавить в избранное мы, к сожалению, не можем, потому что это "стандартная форма".

Теперь посмотрим на функционал этой формы. У нас уже есть одна настройка, потому что это демо-база.

Настройка отображения для категории ^

Попробуем добавить новую.

* Все ошибки
* Прочая ошибка
* Нарушение прав доступа
* Ошибка доступа к локальному файлу
* Ошибка сети
* Ошибка работы с принтером
* Исключение, вызванное из встроенного языка
* Ошибка системы взаимодействия
* Ошибка настроек компоновки данных
* Ошибка сеанса
* Ошибка полнотекстового поиска
* Ошибка внешнего источника данных

Шаблон с текстом ошибки позволяет задать произвольный отформатированный текст, а так же использовать встроенные "параметры".

Чтобы рассмотреть их наглядно, создадим настройку для категории "Все ошибки". И внесём в неё текст со списком всех параметров.

Настройки обработки ошибок применяются после перезапуска сеанса:

Перезапустим сеанс и снова откроем нашу обработку, которая вызовет ошибку.

Вот так выглядят все доступные параметры для пользователя:

Как хранить шаблоны? ^

Вернемся в редактор и рассмотрим небольшой его недостаток и как с ним можно бороться.

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

А далее открыть его в браузере.

И уже с этого файла можно простым копипастом вставить его в поле с настройкой 1С.

Вот, например, содержимое файла:

Это может быть полезным, когда в рамках ТЗ вы разработали шаблон, нужно его как-то передать на внедрение на продуктив. Просто сохраняете HTML.

Настройка пунктов отчета ^

Теперь рассмотрим остальные настройки в редакторе:

Первые две группы параметров относятся к сервису регистрации ошибок. Нужно ли отправлять отчет автоматически или же спрашивать у пользователя. Сам адрес сервиса регистрации, дополнительная информация и так далее.

Сам сервис регистрации ошибок мы рассмотрим позднее следующих публикациях. Попробуем его запустить сами и обработать входящие отчеты об ошибках.

А сейчас рассмотрим третью группу настроек.

Здесь настраиваются пункты, которые будут добавляться в отчет об ошибке.

Давайте сделаем здесь разные варианты. Например, такие:

Перезапустим и вызовем ошибку:

Сразу видим, что список пунктов уменьшился. Те, что мы отключили, в принципе не предполагается к отправке. А обязательные пункты отключить нельзя.

Это очень удобно для разработчиков и администраторов. Мы можем просто запретить пользователям снимать галочки с пунктов, чтобы однозначно увидеть полные данные об ошибке.

Сбросим теперь настройки на Авто (к сожалению, кнопки по сбросу настроек нет).

Настройки для пользователей ^

Помимо общих параметров в редакторе есть ещё и возможность указать точечно настройки для каждого пользователя.

Они работают точно так же, но уже для конкретного пользователя ИБ.

Можно, например, для всех пользователей задать простой текст ошибки, а администратору выводить максимально детализированную информацию (как мы делали в своей настройке с выводом всех возможных параметров).

Программная работа ^

Вернемся к нашей обработке и рассмотрим принцип механизма.

ИнформацияОбОшибке. ЯвляетсяОшибкойКатегории() ^

Что здесь происходит?

Мы пытаемся присвоить "Неопределено" в зарезервированную переменную. Происходит ошибка. Давайте перехватим её при помощи попытки:

В отладке мы видим содержимое информации об ошибке.

Это старый объект в 1С, но он получил новый метод: ЯвляетсяОшибкойКатегории()

Теперь каждая информация об ошибке относится к категориям. И все информации об ошибках относятся к категории "Все ошибки":

Но что нам с этим делать?

ОбработкаОтображенияОшибки() ^

Дело в том, что если ранее мы НЕ перехватывали ошибку через попытку, то она сразу отправлялась на экран пользователю. И мы никак не могли с этим работать.

Но теперь платформа позволяет использовать метод в модуле приложения: ОбработкаОтображенияОшибки()

И теперь, когда возникает ошибка, выполняется этот метод и мы на входе имеем информацию о ней. А так же можем видоизменять представление для пользователя.

Процедура имеет параметры:

Рассмотрим пример из Демо-базы:

Здесь мы видим, что при нарушении прав доступа будет формироваться программно текст с фамилией, именем и номером телефона Иванова Ивана. Номер телефона будет выделен форматированием.

ОбработкаОшибок (МенеджерОбработкиОшибок) ^

На скрине выше мы видим использование новой глобальной переменной ОбработкаОшибок. Тип у переменной МенеджерОбработкиОшибок.

Объект содержит методы, которые позволяют отображать информацию пользователя, получить форматированный текст с учетом настроек в базе, а так же читать и изменять эти самые настройки.

Это даёт разработчику возможность полностью видоизменять отображаемый пользователю форматированный текст.

Если додумать наш код из демо-базы, то ФИО и контактную информацию можно брать из базы. Например, добавить регистр сведений "ОтветственныеЗаОшибки". И в этом регистре указывать физ-лица в разрезе категорий ошибок. А в коде, при возникновении ошибки, выводить пользователю контактные данные этого физ-лица.

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

ОбработкаОшибок. КатегорияОшибкиДляПользователя() ^

В примере из демо-базы используется ещё один метод для определения категории. На этот раз метод относится не к ИнформацияОбОшибке, а к ОбработкаОшибок.

КатегорияОшибкиДляПользователя() возвращает конкретную категорию, к которой относится ошибка. Например, у нас это "непредвиденная ошибка".

Какой метод использовать?

На Зазеркалье использовался метод ИнформацияОбОшибке. ЯвляетсяОшибкойКатегории(). Дело в том, что одна ошибка может относится сразу к нескольким категориям. Цитата:

У объекта ИнформацияОбОшибке есть метод ЯвляетсяОшибкойКатегории(). Одна ошибка может одновременно принадлежать к нескольким категориям.

В описании нового в платформе так же указывается этот метод

Не совсем понятно, почему в демо-базе использовался другой метод. Если у вас есть ответ на этот вопрос, то можете писать в комментарии. Обновлю информацию в статье.

Журнал регистрации ^

Как обстоят дела с фиксацией ошибки в журнале регистрации?

Сейчас мы находимся в отладке в самом начале метода ОбработкаОтображенияОшибки().

Если зайдём в журнал регистрации, то увидим, что ошибка уже в него записана:

То есть, дополнительно фиксировать информацию в журнал регистрации не нужно, даже если мы установим "СтандартнаяОбработка = Ложь". Уже на момент входа в процедуру запись в ЖР есть.

Ошибки внутри ОбработкаОтображенияОшибки() ^

Вот у нас в обработке произошла ошибка. 1С передала управление в метод ОбработкаОтображенияОшибки().

Но что будет, если в этом методе тоже произойдёт ошибка? Как себя поведёт платформа?

Вызовем ошибку внутри процедуры по обработке ошибки (интересно звучит). Для этого попытаемся присвоить "Неопределено" в зарезервированную переменную

Выполняем обработку и видим стандартный текст с инфомацией об ошибке:

Перейдём в формирование отчета:

И посмотрим подробный текст ошибки:

Как видим, это текст ошибки, которая возникла в обработке. Здесь не содержится информация об ошибке, которую мы совершили после.

А что в журнале регистрации?

Опять же только одна ошибка. Та, которая является первопричиной. И нет никаких данных о том, что у нас была ещё и другая.

Дело в том, что когда в процедуре ОбработкаОтображенияОшибки() происходит ошибка, то 1С дальше работает по стандартной логике. Независимо от того, успели ли вы отключить СтандартнуюОбработку.

И в журнале регистрации вторая ошибка (в самом обработчике) фиксироваться не будет.

А что если мы успели сами уже отобразить показать информацию пользователю? Для этого внесём изменения в код:

В этом тексте есть в конце слово "ТЕСТ". А значит, это то окно, которое мы сами программно вызвали.

Но когда мы закроем это окно, 1с откроет новое:

Это окно уже без надписи "ТЕСТ".

Дело в том, что 1С сначала выполнила открытие окна с ошибкой, которое мы выполнили сами, а затем, после того как процедуру ОбработкаОтображенияОшибки() не удалось выполнить, открыла ещё и стандартное окно.

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

Выводы ^

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

В следующих статьях мы продолжим разбирать данных механизм. Создадим свойс htttp-сервис регистрации ошибок. Попробуем реализовать пример использования обработчика ОбработкаОтображенияОшибки(). Будет интересно 👍

Понравилась статья?

Не будьте равнодушными! Поставьте ~~лайк~~ плюс, оставьте комментарий.

Не забудьте посмотреть видео по этой теме, в нём я наглядно показываю всё то, что говорится в статье: Отображение ошибок в 1С (новый механизм с версии 8.3.17)

И переходите к другим публикациям:

Специальные предложения

Что удивительно (это не к автору, а к 1с), это что общая обработка ошибок
— рекомендуется к использованию как чисто клиентская
— происходит после записи в журнал регистрации

А сервер регистрации ошибок у вас не получилось еще поднять? Было бы крайне интересно

подписался на ю-туб канал.

(17) да, в этой статье просто не рассматривается сервис регистрации.

Вот на этом скрине видно, что в первой колонке (Отчет об ошибке) есть пункт «Отправлять отчет». Его просто нужно перевести в «Отправлять». А далее уже нужно иметь готовую систему, которая примет и отработает этот отчет об ошибке.

(20)
Я ещё напишу про это подробнее, но там всё просто:

Погонял на 8.3.19.1150. Поскольку а) мне некогда делать отдельную публикацию типа «Нюансы», и б) всё это сильнейше зависит от релиза и дцать раз ещё поменяется, то кратко отпишусь тут. Что замечено:

Коды ошибок и статусы

Пример кода статуса в заголовке curl

Коды статусов не отображаются в тебе ответа. Они содержатся в хэдере, который может быть не видим по умолчанию.

Заголовок ответа выглядит следующим образом:

Коды состояния довольно тонкие, но когда разработчик работает с API, коды могут быть единственным «интерфейсом», который имеет разработчик. Если получится контролировать сообщения, которые видит разработчик, это будет большой победой юзабилити

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

Можно посмотреть список общих кодов состояния REST API здесь и общий список кодов HTTP статусов здесь. Хотя, возможно, было бы полезно включить несколько стандартных кодов состояния, нет необходимости в полном документировании всех стандартных кодов состояния, особенно если они редко запускаются в API.

Где перечислять HTTP-ответ и коды ошибок

Практичнее, если API будут иметь одну страницу с ответами и кодами ошибок ко всему API. Отдельная страница с перечнем кодов состояния (вместо добавления кода состояния в каждую конечную точку) позволяет более детально описать каждый код без переполнения других частей документации. Такой подход уменьшает избыточность и ощущение информационной перегрузки.

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

Такая стратегия может заключаться в том, чтобы привлечь внимание к каким-либо особенно важным кодам состояния или ошибок для конкретной конечной точки, а затем перейти к централизованной странице «Коды ответов и состояний» для получения полной информации.

Где взять коды ошибок и статусы

Коды состояния и ошибок могут быть неочевидны в документации API. Вероятно, придется попросить разработчиков предоставить список всех кодов состояния и ошибок, которые уникальны для API. Иногда разработчики хардкодят коды состояния и ошибок непосредственно в программном коде, и у них нет простых способов передать полный список (что также затрудняет локализацию).

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

Как перечислять коды ошибок

Коды статусов и ошибок можно привести в виде списка определений или таблицы, например так:

Status code	Значение
200	Успешный запрос и ответ
400	Неверно заданные параметры или другой неверный запрос

Коды состояния и ошибок помогают в устранении неполадок

Коды состояния и ошибок особенно полезны при устранения неполадок. Таким образом, можно рассматривать коды ошибок как дополнение к разделу по устранению неполадок.

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

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

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

Примеры кодов статусов и ошибок

Ниже приведены несколько вариантов разделов с кодами статусов и ошибок.

Context. io

Clearbit не только документирует стандартные коды состояния, но также описывает уникальные параметры, возвращаемые их API. Большинство разработчиков, вероятно, знакомы с кодами 200, 400 и 500, поэтому эти коды не требуют много пояснений. Но если API имеет уникальные коды, описывать их нужно адекватно и подробно.

Twitter

В Twitter не только описывается код и состояние, но также предоставляется полезная информация по устранению неполадок, потенциально помогая в устранении ошибок. Например, про ошибку 500 не просто сказано, что статус относится к неработающей службе, но и есть объяснение: «Обычно это временная ошибка, например, в ситуации высокой нагрузки или если у конечной точки временно возникают проблемы. Посетите форумы разработчиков на случай, если у других возникнут аналогичные проблемы, или повторите попытку позже».

Mailchimp

Mailchimp предоставляет удобочитаемые и понятные описания сообщений об ошибке. Например, в ошибке 403 вместо того, чтобы просто написать «Запрещено», Mailchimp объясняет причины, по которым можно получить ошибку запрещенного кода. У Mailchimp существует несколько типов ошибок 403. Запрос может быть запрещен из-за отключенной учетной записи пользователя или запроса, направленного не в тот центр обработки данных. В случае ошибки «WrongDataCenter» Mailchimp отмечает, что «она часто связана с неправильно настроенными библиотеками» и ссылается на дополнительную информацию о центрах обработки данных. Такой тип документации кода ошибки очень полезен для пользователей.

Flickr

В Flickr раздел «Коды ответов» встроен в описание каждой адресной темы API. Описания ошибок выглядят короткими. Хотя встраивание кодов ответов в каждую тему делает коды ошибок более заметными, в некоторых случаях такой подход менее полезен. Поскольку он встроен в каждую тему API, описания кодов ошибок должны быть краткими, иначе их содержимое будет перегружено информацией о запросе конечной точки.

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