4 как можно очистить протокол ошибок

Обновлено: 15.05.2024

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

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

Общие сведения про журнал событий

Чисто физически журнал является набором файлов с расширением .evtx. Они содержат текстовые данные и хранятся в системной папке:

Как зайти в журнал событий в Windows 10

А второй требует использования панели управления, где требуется:

Попав в журнал событий в Windows 10, можно приступить к разбору его интерфейса.

Приложение (основная) — записи, созданные программами.
Безопасность (основная) — сведения о безопасности системы.
Установка (дополнительная).
Система (основная) — сведения о работе системных компонентов.
Перенаправленные события (дополнительная).

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

Нюансы работы в журнале событий

Число обозреваемых событий может исчисляться тысячами и даже десятками тысяч. Для создания комфортных условий работы журнал событий в Windows 10 оснащен встроенным фильтром. Он позволяет отсортировать имеющуюся информацию по:

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

Поиск описания потребует выхода в интернет и посещения сайта Microsoft. Или иных ресурсов, предоставляющих подобную информацию.

Стоит упомянуть, что наличие ошибок – нормальное явление ОС. Любые, даже самые незначительные сбои вносятся в реестр. Так что не стоит переживать, обнаружив их в журнале.

Как очистить журнал событий в Windows 10

Среди способов, как почистить журнал событий в Windows 10, можно выделить 5 основных.

Ручная очистка журнала

Этот способ весьма прост. Он не требует специальных навыков или дополнительного софта. Все что необходимо, это:

Как вы, наверное, заметили, это самый простой способ. Однако некоторые ситуации требуют прибегнуть к иным методам.

Создание файла .bat

Этот способ также позволяет быстро провести очистку. Для его реализации вам потребуется код:

Его необходимо использовать в следующем алгоритме:

После этого все отчеты будут удалены.

Очистка через командную консоль

Очистить журнал событий в Windows 10 можно и при помощи данного инструмента. Для этого потребуется:

Чистка журнала событий через PowerShell

PowerShell – более продвинутая версия командной строки. Очистка журнала событий с его помощью проводится аналогичным образом. За исключением вводимой команды. В данном случае она имеет следующий вид:

При помощи программы CCleaner

Эта прекрасная программа занимается очисткой системы Windows. В том числе и записей в журнале событий. А значит вы можете не только избавится от данных, но и ускорить работу системы. Для этого:

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

Нам очень приятно! Не могли бы вы поделиться этой статьей с друзьями? А также мы будем рады, если вы оставите комментарий.

Lexia (DiagBox), и активация скрытых возможностей

Дополнительное оборудование и аксессуары. Аксессуары улучшающие как внешний вид Ситроен С4 Седан, так и его характеристики. Чип-тюнинг.

Lexia (DiagBox), и активация скрытых возможностей

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

В этой теме не ищут владельцев Лексий, их ищут в другом месте!
За подобные вопросы в данной теме будут раздаваться "награды".

Единственное верное и полное название сканера - PSA XS Evolution , который работает с программным обеспечением:
. Lexia для автомобилей Citroen;
. Peugeot Planet 2000 для автомобилей Peugeot;
. PSA Diagbox - это новая программа, которая является оболочкой для Lexia и PP2000.
Однако в массах закрепилось название сканера Lexia 3 .

Яндекс Диск , и отдельные файлы, кому это надо на Яндекс Диск
Обновления от другого "производителя".
источник

Само оборудование бывает FullChip (дороже) и обычное. Разница в количестве распаянных на плате элементов. В принципе работают оба варианта, но фуллчип считается более надежным, менее глючным, и менее привередливым к качеству питания (в частности версии НЕфуллчип рекомендуется использовать на ноутбуках только при питании от аккумулятора, БЕЗ подключения шнура питания).
Так же есть версии (неважно фуллчип или нет) B и C. Опять же, работают обе, но версия C - более современна, по идее должна позволять работать с более широким спектром машин (включая самые новейшие). На нашей машине версия B (если шнурок сам по себе не глючный) тоже работает.
Какую версию нужно взять? Ответ здесь (начало чуть выше, продолжение чуть ниже)

Что такое Lexia, DiagBox можно развёрнуто почерпнуть у наших соседей:
Разъяснения новичкам про Lexia, DiagBox
Все, что вы делаете - вы делаете на свой страх и риск. Делай бэкапы всех пунктов прежде чем что либо менять!
Форум за ваши действия никакой ответственности не несет.
Если Вы не уверены в последствиях и своих знаниях и навыках - значит не делайте!

Готовые образы раз и два виртуальной машины и развернутой Лексии.

При импорте виртуалки не ставьте галочку регенерировать МАК

Что вообще можно активировать и вкратце - как это делать:
(зависит от комплектации)

Собрал в одну кучу то что можно активировать чтоб по всей теме не бегать и не искать. Если что забыл, пишите, дополним.
Включение настроек автомобиля в дисплее C
EMF_C_UDS -> Конфигурирование автомобиля -> Вывод меню регулировок автомобиля - "Активировано"
Включение ДХО + габариты
BSI2010 -> Подсветка Сигнализация -> Одновременное включение дневного режима света фар и габаритных огней - "Да"
Включение боковой светомаркировки
BSI2010 -> Подсветка Сигнализация -> Присутствие стояночных фонарей (боковой светомаркировки) - "Да"
Включение меню (активация работоспособности имеющегося в нештатных ГУ меню) отключения ДХО
BSI2010 -> Подсветка Сигнализация -> Наличие функции фар дневного освещения в меню персональных настроек - "Да"
( примечание - помимо отключения/включения в БК, чтобы отключились/включились ДХО, нужно еще либо повернуть переключатель положения света 0-габариты или наоборот, либо оставаясь в 0 положении - перезапустить двигатель)
Индикатор рекомендуемой передачи
BSI2010 -> Информация Водителя -> Наличие индикатора рекомендуемой передачи (коробки переключения передач) - "Да"
OIL OK (только для двигателей серии EP6)
BSI2010 -> Информация Водителя -> Источник информации об уровне масла - "Калькулятор контроля двигателя"
Включение штатной сигнализации для работы режима "Slave"
BSI2010 -> Защита - Двери и крышки - Механическое усиление -> Тип сигнализации - "Стандартная охранная сигнализация"
Включение Открытия багажника отдельно от дверей автомобиля
BSI2010 -> Защита - Двери и крышки - Механическое усиление -> Тип селективности открытия задней двери с дистанционного пульта - "Открытием"
Затем необходимо еще поставить галку/выбор в БК. Для RT6 путь особый, "багажник" в разделе - параметры авто - доступ к авто - разблокировка дверей и крышки багажника - тут надо галку поставить. Но для появления этого меню может понадобиться сделать это.
Включение программируемого круиза
BSI2010 -> Помощь в вождении -> Наличие программируемой системы круиз-контроля - "Да"
Включение функции динамичного вождения или ФДВ
BSI2010 -> Комфорт при вождении -> Наличие функции динамичного вождения - "Присутствует"
BSI2010 -> Комфорт при вождении -> Тип функции динамичного вождения - "Частичный (только управление двигателем и коробкой передач)"
BSI2010 -> Разное -> Тип функции динамичного вождения - "Частичный (только управление двигателем и коробкой передач)"
Перевод на работу по циклу Евро-4
BSI2010 -> Двигатель -> Тип образования момента коробки передач ставим "Евро4".

Отключение "пищалок" ремней безопасности
Прописывание ключей в автомобиль
Включение программируемого круиза на комплектациях, где есть только обычный круиз (для Динамиков нужно еще менять педаль газа, для Тендансов - не нужно, нужно просто активировать).
Включение Открытия багажника отдельно от дверей автомобиля, и еще дополнительные скрины и описание, и тут - описание и практический опыт (и пояснения нюансов), а тут особенности для RT6.
Активация подрулевых лепестков (лепестки надо докупить).
Еще можно посмотреть тему из раздела FAQ

Плюсить в репу за скрины - Technics66 , Totosha .

Официальный DiagBox 9

Мое доп. оборудование: ГУ RoadNav S100 + камера ЗВ Roadnav CP6457 + WiFi COMFAST CF-WU720N; Focal ISS 165 (фронт) на усилке DLS XM20 + JBL CS-6 (тыл) от ГУ; парктроник Parkmaster 4-XJ-51; светодиодные ДХО + световодные фонари в крышке багажника.

Существует две фундаментальные стратегии: обработка исправимых ошибок (исключения, коды возврата по ошибке, функции-обработчики) и неисправимых ( assert() , abort() ). В каких случаях какую стратегию лучше использовать?

Виды ошибок

Ошибки возникают по разным причинам: пользователь ввёл странные данные, ОС не может дать вам обработчика файла или код разыменовывает (dereferences) nullptr . Каждая из описанных ошибок требует к себе отдельного подхода. По причинам ошибки делятся на три основные категории:

Пользовательские ошибки

Сделаю очень громкое заявление: такие ошибки — на самом деле не ошибки.

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

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

Конечно, такое не всегда возможно. Иногда проверять вводимые данные слишком дорого, иногда это не позволяет сделать архитектура кода или разделение ответственности. Но в таких случаях ошибки должны обрабатываться однозначно как исправимые. Иначе, допустим, ваша офисная программа будет падать из-за того, что вы нажали backspace в пустом документе, или ваша игра станет вылетать при попытке выстрелить из разряженного оружия.

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

Системные ошибки

Обычно системные ошибки нельзя предсказать. Более того, они недетерминистские и могут возникать в программах, которые до этого работали без нареканий. В отличие от пользовательских ошибок, зависящих исключительно от вводимых данных, системные ошибки — настоящие ошибки.

Но как их обрабатывать, как исправимые или неисправимые?

Это зависит от обстоятельств.

Многие считают, что ошибка нехватки памяти — неисправимая. Зачастую не хватает памяти даже для обработки этой ошибки! И тогда приходится просто сразу же прерывать выполнение.

Но падение программы из-за того, что ОС не может выделить сокет, — это не слишком дружелюбное поведение. Так что лучше бросить исключение и позволить catch аккуратно закрыть программу.

Но бросание исключения — не всегда правильный выбор.

Кто-то даже скажет, что он всегда неправильный.

Если вы хотите повторить операцию после её сбоя, то обёртывание функции в try-catch в цикле — медленное решение. Правильный выбор — возврат кода ошибки и цикличное исполнение, пока не будет возвращено правильное значение.

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

Программистские ошибки

Это худший вид ошибок. Для их обработки я стараюсь сделать так, чтобы мои ошибки были связаны только с вызовами функций, то есть с плохими параметрами. Прочие типы программистских ошибок могут быть пойманы только в runtime, с помощью отладочных макросов (assertion macros), раскиданных по коду.

При работе с плохими параметрами есть две стратегии: дать им определённое или неопределённое поведение.

Если исходное требование для функции — запрет на передачу ей плохих параметров, то, если их передать, это считается неопределённым поведением и должно проверяться не самой функцией, а оператором вызова (caller). Функция должна делать только отладочное подтверждение (debug assertion).

С другой стороны, если отсутствие плохих параметров не является частью исходных требований, а документация определяет, что функция будет бросать bad_parameter_exception при передаче ей плохого параметра, то передача — это хорошо определённое поведение (бросание исключения или любая другая стратегия обработки исправимых ошибок), и функция всегда должна это проверять.

В качестве примера рассмотрим получающие функции (accessor functions) std::vector : в спецификации на operator[] говорится, что индекс должен быть в пределах валидного диапазона, при этом at() сообщает нам, что функция кинет исключение, если индекс не попадает в диапазон. Более того, большинство реализаций стандартных библиотек обеспечивают режим отладки, в котором проверяется индекс operator[] , но технически это неопределённое поведение, оно не обязано проверяться.

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

Когда нужно проверять только с помощью отладочных подтверждений, а когда — постоянно?

Но конечное решение зависит от многих других факторов, так что очень трудно дать какой-то общий совет. По умолчанию я стараюсь свести к неопределённому поведению и использованию только подтверждений. Иногда бывает целесообразно обеспечить оба варианта, как это делает стандартная библиотека с operator[] и at() .

Хотя в ряде случаев это может быть ошибкой.

Об иерархии std::exception

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

Я предлагаю наследовать только от одного из этих четырёх классов:

std::bad_alloc : для сбоев выделения памяти.
std::runtime_error : для общих runtime-ошибок.
std::system_error (производное от std::runtime_error ): для системных ошибок с кодами ошибок.
std::logic_error : для программистских ошибок с определённым поведением.

Подведём итоги

Есть два пути обработки ошибок:

как исправимые: используются исключения или возвращаемые значения (в зависимости от ситуации/религии);
как неисправимые: ошибки журналируются, а программа прерывается.

Есть три основных источника ошибок, каждый требует особого подхода:

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

Гибкие методики обработки ошибок в C++

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

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

В C++ есть два основных подхода: коды возврата ошибок и исключения. Сегодня широко распространено использование исключений. Но некоторые не могут / думают, что не могут / не хотят их использовать — по разным причинам.

Я не буду принимать чью-либо сторону. Вместо этого я опишу методики, которые удовлетворят сторонников обоих подходов. Особенно методики пригодятся разработчикам библиотек.

Проблема

Я работаю над проектом foonathan/memory. Это решение предоставляет различные классы выделения памяти (allocator classes), так что в качестве примера рассмотрим структуру функции выделения.

Для простоты возьмём malloc() . Она возвращает указатель на выделяемую память. Если выделить память не получается, то возвращается nullptr , то есть NULL , то есть ошибочное значение.

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

Это приводит нас к ситуации, когда чередуются нормальные и ошибочные ветви кода. Исключения в таком случае выглядят более подходящим решением. Благодаря им вы сможете обрабатывать ошибки только тогда, когда вам это нужно, а в противном случае — достаточно тихо передать их обратно вызывающему.

Это можно расценить как недостаток.

Учитывая вышесказанное, можно утверждать, что вам следует использовать исключения в качестве механизма обработки ошибок. Этого мнения придерживается большинство разработчиков на С++, включая и меня. Но проект, которым я занимаюсь, — это библиотека, предоставляющая средства выделения памяти, и предназначена она для приложений, работающих в реальном времени. Для большинства разработчиков подобных приложений (особенно для игроделов) само использование исключений — исключение.

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

Так что же делать?

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

К счастью, я могу определить, что вы делаете, когда обнаруживаете ошибку нехватки памяти: чаще всего вы журналируете это событие и прерываете программу, поскольку она не может корректно работать без памяти. В таких ситуациях исключения — просто способ передачи контроля другой части кода, которая журналирует и прерывает программу. Но есть старый и эффективный способ передачи контроля: указатель функции (function pointer), то есть функция-обработчик (handler function).

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

Я называю такой подход обработкой исключений и придерживаюсь его при работе с памятью.

Решение 1: обработчик исключений

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

Поскольку это входит в область видимости класса исключений, вам не нужно именовать каким-то особым образом. Отлично, нам же легче.

Если исключения включены, то для удаления обработчика можно использовать условное компилирование (conditional compilation). Если хотите, то также напишите обычный подмешанный класс (mixin class), дающий требуемую функциональность.

Конструктор исключений элегантен: он вызывает текущую функцию-обработчика, передавая ей требуемые аргументы из своих параметров. А затем комбинирует с последующим макросом throw :

Если у вас включена поддержка исключений, то будет создан и брошен объект-исключение, всё как обычно. Но если поддержка выключена, то объект-исключение всё равно будет создан, и — это важно — только после этого произойдёт вызов std::abort() . А поскольку конструктор вызывает функцию-обработчика, то он и работает, как требуется: вы получаете точку настройки для журналирования ошибки. Благодаря же вызову std::abort() после конструктора пользователь не может нарушить постусловие.

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

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

А если я хочу продолжить работу после бросания исключения?

Методика с обработчиком исключений не позволяет этого сделать в связи с постусловием кода. Как же тогда продолжить работу?

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

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

Для примера снова возьмём функцию выделения памяти. В этом случае я использую такие функции:

При сбое выделения памяти первая версия возвращает nullptr и устанавливает error_code в коде ошибки. Вторая версия не возвращает nullptr , зато бросает исключение. Обратите внимание, что в рамках первой версии очень легко реализовать вторую:

Не делайте этого в обратной последовательности, иначе вам придётся ловить исключение, а это дорого. Также это не даст нам скомпилировать код без включённой поддержки исключений. Если сделаете, как показано, то можете просто стереть другую перегрузку (overload) с помощью условного компилирования.

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

Решение 2: предоставить две перегрузки

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

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

Пожалуйста, не используйте глобальную переменную errno или что-то типа GetLastError() !

Если возвращаемое значение не содержит недопустимое значение для обозначения сбоя, то по мере возможности используйте std::optional или что-то похожее.

Перегрузка исключения (exception overload) может — и должна — быть реализована в рамках версии с кодом ошибки, как это показано выше. Если компилируете без исключений, сотрите перегрузку с помощью условного компилирования.

std::system_error

Подобная система идеально подходит для работы с кодами ошибок в С++ 11.

Она возвращает непортируемый (non-portable) код ошибки std::error_code , то есть возвращаемый функцией операционной системы. С помощью сложной системы библиотечных средств и категорий ошибок вы можете добавить собственные коды ошибок, или портируемые std::error_condition . Для начала почитайте об этом здесь. Если нужно, то можете использовать в функции кода ошибки std::error_code . А для функции исключения есть подходящий класс исключения: std::system_error . Он берёт std::error_code и применяется для передачи этих ошибок в виде исключений.

Эту или подобную систему должны использовать все низкоуровневые функции, являющиеся закрытыми обёртками ОС-функций. Это хорошая — хотя и сложная — альтернатива службе кодов ошибок, предоставляемой операционной системой.

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

std::expected

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

А глобальные переменные вообще не вариант!

В № 4109 предложено решение: std::expected . Это шаблон класса, который также хранит возвращаемое значение или код ошибки. В вышеприведённом примере он мог бы использоваться так:

В случае успеха std::expected будет хранить не-null указатель памяти, а при сбое — std::error_code . Сейчас эта методика работает при любых возвращаемых значениях. Комбинация std::expected и функции исключения определённо допускает любые варианты использования.

Заключение

Если вы создаёте библиотеки, то иногда приходится обеспечивать максимальную гибкость использования. Под этим подразумевается и разнообразие средств обработки ошибок: иногда требуются коды возврата, иногда — исключения.

Одна из возможных стратегий — улаживание этих противоречий с помощью обработчика исключений. Просто удостоверьтесь, что когда нужно, то вызывается callback, а не бросается исключение. Это замена для критических ошибок, которая в любом случае будет журналироваться перед прерыванием работы программы. Как таковой этот способ не универсален, вы не можете переключаться в одной программе между двумя версиями. Это лишь обходное решение при отключённой поддержке исключений.

Более гибкий подход — просто предоставить две перегрузки, одну с исключениями, а вторую без. Это даст пользователям максимальную свободу, они смогут выбирать ту версию, что лучше подходит в их ситуации. Недостаток этого подхода: вам придётся больше потрудиться при создании библиотеки.

Где в 1С находится журнал регистрации ошибок?

Рис.1 Путь к журналу

Рис.3 Запуск журнала из конфигуратора

Рис.4 Добавление в избранное

Как открыть журнал регистрации?

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

Рис.5 Переход к отбору

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

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

Рис.6 Разделы отборов журнала

Как отключить журнал регистрации?

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

Рис.7 Настройка журнала регистрации

Рис.8 Остановка записи событий в журнал

Как выгрузить журнал регистрации?

Рис.9 Выгрузка журнала

Как восстановить журнал регистрации?

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

Зачастую достаточно бывает переноса содержимого этой папки в каталог с новым расположением ИБ, чтобы журнал регистрации восстановился. Если же это не помогло, то придется обращаться к архиву логов или стороннему ПО для восстановления данных журнала регистрации. Перед тем как запускать обработки на рабочей базе, обязательно потренируйтесь на копии ИБ.

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

Как сократить журнал регистрации?

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

Рис.10 Как уменьшить размер истории ошибок и действий

В сокращении журнала регистрации нам помогут 2 функции:

Рис.11 Разделение по периодам

Как очистить журнал регистрации?

Логи 1С хранятся в папке 1Cv8Log в каталоге расположения информационной базы. Чтобы очистить журнал регистрации достаточно просто удалить данную директорию вместе с содержимым. Это освободит немало места на жестком диске, но рекомендуется произвести архивирование журнала и переместить данные в другое место.

Можно ли программно добавить запись в журнал?

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

Как вернуть старый формат журнала регистрации?

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

Чтобы снова увидеть файл формата lgf, нужно для каждой базы 1С проделать следующий алгоритм:

Найдите папку 1Cv8Log для конкретной базы;
Удалите из каталога все файлы. Желательно сохранить их в другом месте;
Создайте в папке 1Cv8Log пустой файл формата 1Cv8.lgf.

Вышеперечисленный алгоритм проделайте для каждой информационной базы.

Можно ли перенести журнал регистрации в отдельную базу?

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

Процедура переноса журнала отличается при файловом и клиент-серверном варианте информационной базы. В первом случае вам достаточно лишь найти в старом каталоге базы папку 1Cv9Log и скопировать ее в новую директорию базы.

Второй случай сложнее, так как потребуется исправлять идентификатор ИБ. Для этого откройте файл 1Cv8Reg, расположенный на сервере, и найдите в нем строчку с указание ID – источника ИБ. Зайдите в каталог этой ИБ и перенесите оттуда в новую директорию папку 1Cv8Log. Также следует внести изменения в адреса сервера, если базу перенесли.

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

Читайте также: