Здравствуйте, коллеги.

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

while(условие)
{
    try
    {
        throw exception();
    }
    catch(exception ex)
    {
        log << ex.what();
    }
}

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

Здравствуйте, xednay89, Вы писали:

X>После такого весь лог заваливается однотипными сообщениями, среди которых можно не заметить что-то важное.
X>Какой подход здесь можно применить, чтобы и не заваливать лог, и не пропускать никаких важных событий?

void syslog(
  int priority, // <--- тут от LOG_DEBUG и до ...
  const char *format, ...);

Здравствуйте, Mystic, Вы писали:

M>

M>void syslog(
M>  int priority, // <--- тут от LOG_DEBUG и до ...
M>  const char *format, ...);
M>

Это не решает проблему.
Если у меня в цикле возникает событие с очень важным приоритетом?

X>По-моему, вполне типичная ситуация:
X>Программа имеет некий лог (например, прям на интерфейсе). В ходе выполнения что-то идет не так и генерируется исключение (или любое другое событие, о котором нужно сделать запись в лог). Информация об этом исключении записывается в лог.
X>Но вот как быть в такой ситуации?

X>После такого весь лог заваливается однотипными сообщениями, среди которых можно не заметить что-то важное.
X>Какой подход здесь можно применить, чтобы и не заваливать лог, и не пропускать никаких важных событий?

Простой вариант:
Откройте Google Chrome developer tools (Ctrl+Shift+I), нажмите Esc, напишите for(var i=1;i<4;i++){console.log('message1')}

Сложный:
Хранить не одно последнее сообщение, как в предыдущем примере, а N последних уникальных. И увеличивать им счётчики.

Здравствуйте, xednay89, Вы писали:

X>Если у меня в цикле возникает событие с очень важным приоритетом?

Это уже настройки твоего syslog, в частности syslogd по умолчанию не помещает одинаковые сообщения.

Здравствуйте, xednay89, Вы писали:

X>После такого весь лог заваливается однотипными сообщениями, среди которых можно не заметить что-то важное.
X>Какой подход здесь можно применить, чтобы и не заваливать лог, и не пропускать никаких важных событий?
Логируй с разными уровнями. Пронаследуйся от exception и задай возможность указывать уровень severity.

Здравствуйте, xednay89, Вы писали:

X>Какой подход здесь можно применить, чтобы и не заваливать лог, и не пропускать никаких важных событий?

Вводят дискриминанты. Обычно уровень(приоритет) и источник.

X>После такого весь лог заваливается однотипными сообщениями, среди которых можно не заметить что-то важное.
X>Какой подход здесь можно применить, чтобы и не заваливать лог, и не пропускать никаких важных событий?

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

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

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

Здравствуйте, xednay89, Вы писали:

X>После такого весь лог заваливается однотипными сообщениями, среди которых можно не заметить что-то важное.
X>Какой подход здесь можно применить, чтобы и не заваливать лог, и не пропускать никаких важных событий?

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

На уровне "микроменеджмента" эту задачу можно решить, например, так. Заводим счётчик исключений, пойманных в этой точке, и всегда его инкрементируем. (Чтобы не переполнялось в реальной ситуации, сделать его 64-битным.) Далее, если его значение ниже, например, 100, логгируем исключение, иначе — игнорируем. Чуть более широкий вариант: отдельный счётчик логгированных исключений, который сбрасывается, например, раз в час. Ещё более широкий: применить старый добрый token bucket. Например, добавляем разрешение логгировать 1 штуку в минуту, а ёмкость корзины — 100 разрешений. Тогда, если неожиданно возникает проблема, она будет описана в полном виде, а постоянно капающая на мозги — только началом. Дальше можно развивать эту схему добавкой приоритетов исключений и раздельными ограничениями для каждой группы.

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

Здравствуйте, xednay89, Вы писали:

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

В итоге сделали градацию приоритетов:

DEBUG — любой спам все что хочется записать в лог.( Любимые цитаты, анекдоты, и т.п. ну вобщем ты понял)
INFO — то что выглядит как осмысленная информация, может быть полезна для диагностики.
WARN — произошла ошибка, на текущем уровне мы не можем ее обработать и предполагаем что код выше имеет шансы сделать что-то разумное
ERROR — произошла ошибка и сделать точно ничего нельзя.
FATAL — мир перевернулся с ног на голову. Скоро взлетаем, пора пристегнуть ремни.

В итоге сдандартный лог проблемы выглядит так:
WARN ....
WARN .....
ERROR .....!!!!

На выходе получилась портянка, руками разбирать ее не реально. Поэтому к этой портянке прикрутили logparser.
Есть как консольный вариант так и различные GUI.

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

В итоге:

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

минусов незамеченно

Здравствуйте, xednay89, Вы писали:

X>Здравствуйте, коллеги.

X>По-моему, вполне типичная ситуация:
X>Программа имеет некий лог (например, прям на интерфейсе). В ходе выполнения что-то идет не так и генерируется исключение (или любое другое событие, о котором нужно сделать запись в лог). Информация об этом исключении записывается в лог.
X>Но вот как быть в такой ситуации?

X>После такого весь лог заваливается однотипными сообщениями, среди которых можно не заметить что-то важное.
X>Какой подход здесь можно применить, чтобы и не заваливать лог, и не пропускать никаких важных событий?

Ключевое слово — важность исключения.
У программиста, саппорта и пользователя свои важные и не очень приоритеты.

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

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

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

Здравствуйте, __SPIRIT__, Вы писали:

__S>В итоге сделали градацию приоритетов:


Обычно вводят еще уровень TRACE, вот там реальный спам.
А DEBUG это чуть больше логов чем INFO, достаточный чтобы частично или полностью понять проблему и не захламить лог.

Здравствуйте, xednay89, Вы писали:

X>Здравствуйте, коллеги.

X>

X>while(условие)
X>{
X>    try
X>    {
X>        throw exception();
X>    }
X>    catch(exception ex)
X>    {
X>        log << ex.what();
X>    }
X>}
X>

X>После такого весь лог заваливается однотипными сообщениями, среди которых можно не заметить что-то важное.
X>Какой подход здесь можно применить, чтобы и не заваливать лог, и не пропускать никаких важных событий?

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

Однозначно вывод производить за циклом.