Хоть убейте меня – не понимаю!
… почему программисты, уже озаботившиеся ведением подробного журнала о том, что, где и когда случилось, никак не позаботились о том, чтобы фатальные ошибки находились сразу, простым текстовым поиском? Нет ну серьезно, уровни важности сообщений – есть. Вывод сообщения на каждый чих – есть. Ключевые слова (trace, info, warning & error) – есть! Но найти что именно сломалось в этом многомегабайтном монстре никак не получается. Сообщений об ошибках либо нет, либо их очень много и не по делу. Или еще хуже – финальное сообщение «Ой! Тут что-то поломалось!» есть, а чем оно вызвано – нет. Или есть, но пару десятков тысяч строк текста тому назад…
P.S. Agrhh!
Upd: Нашел что падало. Банальный Access Violation. В логах – ничего. От отладчика его тоже спрятали. Ууу! Сатрапы!
Даешь имя файла, ревизию и номер строки кода при обработке препроцессором!
Это, как раз не проблема. Проблема – найти нужную строку.
Строку в логе (из множества таких-же строк), порожденную конструкцией программы или наоборот, имея в сообщении имя файла, ревизию и номер строки кода? Это как в том анекдоте “Нужно найти X. Да вот же он, на доске!”.
В том-то и дело, что строчку лога. Хотя бы сообщение о том, что произошло. Где – это уже будет приятный бонус.
Искренне сочувствую… видимо им казалось, что человек, который будет сопровождать программу бедет знать ее внутренности так же как они.
Это, кроме всего прочего, – массовое явление. Т.е. таких логов большинство.
В мою бытность программистом – мы в каждое сообщение об ошибке вставляли уникальный ID. Это было удобно и программисту, и эксплуатанту. Эксплуатант получал сообщение об ошибке, сообщал ID – и программист сразу знал, какую ветку дерева вытаскивать для решения проблемы.
Самые же XXX сообщения об ошибках выдают изделия MS – все эти сообщения типа “0×800ccc0f”. Ранее я я думал, что в MS есть некая общая база и можно получить доступ к методу UnXXX.
Оказалось, что внутри MS… НЕСКОЛЬКО таких баз и продукты из разных продуктовых групп вполне могут выдавать одинаковые коды ошибок.
Тьфу.
Это безусловно очень удобно, но проблема не в том, чтобы сопоставить сообщение и код. Проблема в том, чтобы найти сообщение в логе. Вернее – понять какое из сообщений оносится к проблеме.
Да, без шаманства не обходится. Не то, чтобы в защиту Microsoft, а так, для информации, добавлю, что отдельные подразделения MS бывает мало чем отличаются от разных компаний. Причина очень прозаическая – на их унификацию, стандартизацию и т.д. требудется слишком много усилий, которые вполне можно наприамить на что-то более полезное. Более того, во многих случаях тесная интеграция вредит.
Еще интереснее получается, когда выполняется одно дело, а код пишет related-сообщения в разные журналы. Да еще асинхронно и с временнЫми метками.
В самом простом случае получается нечто вот такое:
Журнал 1
01:01 info started process A
01:02 info started process B
01:03 info stopped process B
01:04 info stopped process A
Журнал 2
01:02 err process B failed
На самом деле, конечно, происходит следующее:
01:01 info started process A
01:02 info started process B
* тут процесс валится
01:02 err process B failed
* получаем сообщение об остановке процесса, действительную причину остановки можно узнать только из журнала 2
01:03 info stopped process B
* получаем сообщение об остановке процесса A, но реальную причину остановки можно узнать, только из информации по остановке процесса B
* да еще нужно знать про зависимость A от B
01:04 info stopped process A
Легко представить, во что превращается отладка, если процессов штук 20 и журналов не меньше. И некоторые из процессов кросс-зависимы.
Медвежуть!
“простым текстовым поиском” – а как вы видите этот процес? Всмыле в логе как то должно сообщаться что сообщение об ОШИБКЕ, а не просто? Или как то-то по другому?
Это лог некоего долгоиграющего процесса, который может завершиться либо успешно, либо с ошибкой. В лог в любом случае пишется ход процесса – что было сделано, в основном. Большая часть сообщений помечается тегом категории (info, warning, error). В моём случае этот процесс завершается невнятным сообщением «Что-то поломалось». Это практически буквальный перевод. Что именно поломалось – хз. Мне нужно быстро найти что именно поломалось.
Поиск по “Error”, “Fail”, “Failure”, “STATUS_[^S]” и т.д. не показывает ничего конкретного – находится лишь случайный мусор. Более того, сравнение двух логов: «хорошего» и «плохого», тоже ничего не даёт. В «плохом» просто отсутствует здоровенный кусок.
Судя по всему, это не так просто.. Я, конечно, делитант. Но мне кажется, что если чего-то еще не сделали, то просто пока не знают как это сделать.
Комп и прога, они и есть комп и прога.. Они не достаточно сообразительны, для того, чтобы на каждый чих выдавать, в чем конкретно ошибка.. Особенно, если она не синтаксическая, а сематническая например!
Дык сделали. Если пользователю выдается сообщение, что что-то пошло не так, то программа как минимум знает, где что-то пошло не так.
P.S. Линк потёр. Утомили спаммеры.
Потому что нигде этому не учат, надо понимать.
Сколько раз встречалось в коде что-то вроде: if (a != expectedA) logErrorAndThrow( “Wrong a!” ). И очень редко что-то вроде “Wrong a! Expected: ” << expectedA << “, but received ” << a << “.”.
Или вот классы ексепшнов обычно пишут как принимающие строку what сразу на вход, поэтому люди леняться создавать ostringstream и аккуратно в него все логировать перед каждым throw, а пишут просто throw SomeException(”Wrong A”). И оправдания вобщем-то логичные — полное логирование in place засорит код, плюс если исключение словится и обработается, то все конструирование потока с логом будет лишним потреблением ресурсов…
А по-хорошему надо всего-то не полениться и нарисовать подкласс “throw WrongA( a, expectedA)” и все остальное положить в what(). И читаемость, и оптимальное логирование (особенно если what() вызовется отдельным потоком).
Хоть в одном примере Страуструпа такое есть? Да никогда. =\
Такое должно даваться на “Design Patterns” курсах.
Другая песня — когда логирование проходит через код ошибки, который является индексом массива строк-сообщений, который является глобальной константой и лежит чёрт-знает где (в файле ресурсов, например). При вычитке лога (если не используются __FILE__/__LINE__) очень весело искать последовательно всю эту цепочку, чтобы найти то самое место, где произошла ошибка…