День добрый!
Помогите решить задачку или найти подход к ее решению.
В программе необходимо обеспечить высокую информативность диагностических сообщений, для быстрого поиска и устранения причин сбоя. Кто что использует?
Поделюсь своими мыслями ...
Вести просто журнал в текстовом файле ИМХО не очень удобно, так как при большом объеме информации (код ошибки, файл, строка, имя класса и функции, текст ошибки, дополнительные данные) на одну запись эта масса текста становится просто нечитабельной. Нет никакой иерархии, и две записи в журнал из одной функции могут разбежаться в стороны из-за большого кол-ва записей из вложенной функции.
Предполагаю создать свой класс для ведения лога с поддержкой иерархии, фиксацией времени. Так же планирую сделать небольшое приложение для чтения лога и естественно поиска с фильтрацией записей по признакам.
Состав данных в одной записи:
время
файл-строка
класс-функция
тип записи (информация, предупреждение, ошибка)
код ошибки (число)
текст ошибки (строка)
дополнительный текст (пока неочень понятно нужно или нет, для всякого мусора в общем)
данные (строка в формате имя переменной=значение\n)
+ ссылка на родительскую запись, т.е. получается дерево вызовов
Хотелось бы получить так же возможность при компиляции (в идеале вообще при выполнении программы, но как???) задавать уровень трасировки от фиксации действий пользователя, до подробнейшего дерева вызовов.
И еще, в коде будут использоваться прерывания ... как бы все это совместить ??? пока предполагаю внутри функции всегда ставить try{}__finally{} для фиксации входа и выхода, иначе дерево в случае ошибки просто умирает (пока фиксирую родительскую запись через push в начале функции и pop в конце (в блоке __finally) - родитель всегда последний).
У кого какие мысли есть по этому поводу? Буду благодарен за любую помощь и подсказку!
Вообще вопрос довольно объемный, думаю многим будет интересно.
Из своей практики ... увы зачастую информативность сообщений продгаммы об ошибке оставляет желать лучшего и для пользователя и для разработчика (зачастую даже автор не может разобраться где же был сбой).
Помогите решить задачку или найти подход к ее решению.
В программе необходимо обеспечить высокую информативность диагностических сообщений, для быстрого поиска и устранения причин сбоя. Кто что использует?
Поделюсь своими мыслями ...
Вести просто журнал в текстовом файле ИМХО не очень удобно, так как при большом объеме информации (код ошибки, файл, строка, имя класса и функции, текст ошибки, дополнительные данные) на одну запись эта масса текста становится просто нечитабельной. Нет никакой иерархии, и две записи в журнал из одной функции могут разбежаться в стороны из-за большого кол-ва записей из вложенной функции.
Предполагаю создать свой класс для ведения лога с поддержкой иерархии, фиксацией времени. Так же планирую сделать небольшое приложение для чтения лога и естественно поиска с фильтрацией записей по признакам.
Состав данных в одной записи:
время
файл-строка
класс-функция
тип записи (информация, предупреждение, ошибка)
код ошибки (число)
текст ошибки (строка)
дополнительный текст (пока неочень понятно нужно или нет, для всякого мусора в общем)
данные (строка в формате имя переменной=значение\n)
+ ссылка на родительскую запись, т.е. получается дерево вызовов
Хотелось бы получить так же возможность при компиляции (в идеале вообще при выполнении программы, но как???) задавать уровень трасировки от фиксации действий пользователя, до подробнейшего дерева вызовов.
И еще, в коде будут использоваться прерывания ... как бы все это совместить ??? пока предполагаю внутри функции всегда ставить try{}__finally{} для фиксации входа и выхода, иначе дерево в случае ошибки просто умирает (пока фиксирую родительскую запись через push в начале функции и pop в конце (в блоке __finally) - родитель всегда последний).
У кого какие мысли есть по этому поводу? Буду благодарен за любую помощь и подсказку!
Вообще вопрос довольно объемный, думаю многим будет интересно.
Из своей практики ... увы зачастую информативность сообщений продгаммы об ошибке оставляет желать лучшего и для пользователя и для разработчика (зачастую даже автор не может разобраться где же был сбой).
Я вовсе не против, но в видимых мной реальных приложениях попытки вести реальный лог вызовов приводили к не возможности использовать программу. Если в вашем случае это не мешает, я только рад. Обычно такие вещи можно навешивать на небольшие сложные участки, где не удается отловить ошибку обычными методами. И уверяю Вас, накладные расходы .NET и Java - это цветочки по сравнению с логом реально всех вызовов.