Отладка и логгирование кода в HTTP-сервисах
Доброго дня!
Подскажите, есть ли возможность включить запись в журнал сообщений для HTTP-сервисов? Сейчас если код крашится внутри сервиса запись об этом событии в журнал не делается, что очень неудобно, поскольку понять что происходит очень сложно. ТП=1С:Предприятие 8.3 (8.3.18.1483) Отладка тоже хромает, потому как если установить точку останова и дождаться всплытия отладчика, то поработать с отладчиком удастся недолго. Следующее событие (отключить их у меня лично целая проблема) приведёт к тому, что текущая отладка прерывается и ты снова оказываешься в установленной точке останова. И так до бесконечности, отладчик будет всплывать вновь и вновь не давая сделать и нескольких шагов. Отключение точки, как и снятие галки "Автоматическое подключение" -> "HTTP-сервисы" не работает нормально.
Подскажите, есть ли возможность включить запись в журнал сообщений для HTTP-сервисов? Сейчас если код крашится внутри сервиса запись об этом событии в журнал не делается, что очень неудобно, поскольку понять что происходит очень сложно. ТП=1С:Предприятие 8.3 (8.3.18.1483) Отладка тоже хромает, потому как если установить точку останова и дождаться всплытия отладчика, то поработать с отладчиком удастся недолго. Следующее событие (отключить их у меня лично целая проблема) приведёт к тому, что текущая отладка прерывается и ты снова оказываешься в установленной точке останова. И так до бесконечности, отладчик будет всплывать вновь и вновь не давая сделать и нескольких шагов. Отключение точки, как и снятие галки "Автоматическое подключение" -> "HTTP-сервисы" не работает нормально.
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
А я немного иначе делаю.
В самой http получаю только параметры, а всю обработку выношу в модуль. ответ из модуля если возвращаю как json, то вкладываю туда ошибку как строку.
Т.о. достигаются три важные вещи
1. мне не нужно отслеживать ошибки в http функции, т.к. там ломаться нечему.
2. я могу спокойно отладить логику, хоть даже обычной обработкой.
3. не создаю лишних ошибок в http связанных с моей логикой. их там и без меня хватает.
В самой http получаю только параметры, а всю обработку выношу в модуль. ответ из модуля если возвращаю как json, то вкладываю туда ошибку как строку.
Т.о. достигаются три важные вещи
1. мне не нужно отслеживать ошибки в http функции, т.к. там ломаться нечему.
2. я могу спокойно отладить логику, хоть даже обычной обработкой.
3. не создаю лишних ошибок в http связанных с моей логикой. их там и без меня хватает.
Пример кода |
|---|
Например, обработка post запроса мог бы выглядеть примерно так:
Функция HTTPPOST(Запрос)
DATA = Запрос.ПолучитьТелоКакСтроку();
Если СтрДлина(DATA)>0 Тогда
jsonСтрока = МойОбщийМодуль.Обработка(DATA);
Ответ = Новый HTTPСервисОтвет(200);
Заголовки = Новый Соответствие;
Заголовки.Вставить("Content-Type","application/json; charset=utf-8");
Ответ.УстановитьТелоИзСтроки(jsonСтрока);
ИНАЧЕ
Ответ = Новый HTTPСервисОтвет(405,"DATA NOT FOUND");
КонецЕсли;
Возврат Ответ;
КонецФункции
'Упрощенно, сама обработка примерно так. Запись в журнал лучше писать с указанием кто сломался, 'тогда проще найти ошибки от конкретного веб сервиса.
Функция Обработка(DATA) Экспорт
Попытка
Ответ = ОбработкаДанных(DATA);
Исключение
Ответ = МойСлужебныйМодуль.ВернутьОшибкуВJson(ОбработкаОшибок.КраткоеПредставлениеОшибки(ИнформацияОбОшибке()));
ЗаписьЖурналаРегистрации("httppost.Обработка",УровеньЖурналаРегистрации.Ошибка, ,ИнформацияОбОшибке(),
ОбработкаОшибок.ПодробноеПредставлениеОшибки(ИнформацияОбОшибке()));
КонецПопытки;
Возврат МойСлужебныйМодуль.ПолучитьОтветJSON(Ответ);
КонецФункции
Показать |
(4)
(4)
Все бы только умничать да поучать. Нет чтобы что-то умное написать.
(4)
DATA
а кто сказал, что в шапке ошибки description должен совпадать с тем, что ты прочитал в документации об ошибке? напиши туда че хочешь. еще скажи что к 500 ошибке обязательно писать Internal Server Error а к 200 только OK.
Все бы только умничать да поучать. Нет чтобы что-то умное написать.
(5) Чуваааак....
Например, ошибку 405 выбрасывает сама 1С, когда лезешь к хттп сервису не тем методом, который прописан в шаблоне. До исполнения кода дело вообще не доходит. И как бедный вызывающий сервис должен понять что происходит? Он не указал тело запроса? Он делает вызов не того метода? Он вообще не туда долбится?
Я ж и говорю - неучи учат неучей.
Например, ошибку 405 выбрасывает сама 1С, когда лезешь к хттп сервису не тем методом, который прописан в шаблоне. До исполнения кода дело вообще не доходит. И как бедный вызывающий сервис должен понять что происходит? Он не указал тело запроса? Он делает вызов не того метода? Он вообще не туда долбится?
Я ж и говорю - неучи учат неучей.
(6) нет возможности запретить 1с принимать от http сервисов post запросы с пустым телом, не попадая в обработку. Если есть, напиши как, я с удовольствием поучусь. В других языках, где есть возможность типизировать post, при попытке передать туда пустоту, выстрелит ошибка.
Если бедный запрос из вне передал мне кукиш вместо осмысленного тела запроса, я его обработать не могу и что-то должен ему ответить. Почему бы не 405 ошибку?
Если тебе не нравится ошибка 405 напиши любую другую или не пиши ничего это твое личное дело.
Если бедный запрос из вне передал мне кукиш вместо осмысленного тела запроса, я его обработать не могу и что-то должен ему ответить. Почему бы не 405 ошибку?
Если тебе не нравится ошибка 405 напиши любую другую или не пиши ничего это твое личное дело.
Ну господа! Ваши желания и амбиции мне ясны. Но всё-же! Как включить штатную запись ошибок в журнал? Это вообще возможно? У меня в сервисах тысячи строк. И где-то там по дороге иногда что-то крашится. Причём по шпионски молчаливо! Выяснить это помогла бы элементарная запись в журнале, типа - вот в этой строке вот это нехорошо. Но 1С не любит разбрасываться словами. Вариант из (2) вроде выглядит приемлемо. Но господи! Неужели и тут костылить нужно ради обретения душевного равновесия?
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот