Comments on: Хоть убейте меня – не понимаю!

By: Not a kernel guy

Not a kernel guy — Sun, 03 Feb 2008 02:32:15 +0000

Такое должно даваться на “Design Patterns” курсах.

By: alexandroid

alexandroid — Sat, 02 Feb 2008 22:03:59 +0000

Другая песня — когда логирование проходит через код ошибки, который является индексом массива строк-сообщений, который является глобальной константой и лежит чёрт-знает где (в файле ресурсов, например). При вычитке лога (если не используются __FILE__/__LINE__) очень весело искать последовательно всю эту цепочку, чтобы найти то самое место, где произошла ошибка…

By: alexandroid

alexandroid — Sat, 02 Feb 2008 22:01:20 +0000

Потому что нигде этому не учат, надо понимать.

Сколько раз встречалось в коде что-то вроде: 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() вызовется отдельным потоком).

Хоть в одном примере Страуструпа такое есть? Да никогда. =\

By: Not a kernel guy

Not a kernel guy — Thu, 31 Jan 2008 17:49:36 +0000

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

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

P.S. Линк потёр. Утомили спаммеры.

By: Костя

Костя — Thu, 31 Jan 2008 10:06:56 +0000

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

By: Not a kernel guy

Not a kernel guy — Fri, 25 Jan 2008 21:08:45 +0000

В том-то и дело, что строчку лога. Хотя бы сообщение о том, что произошло. Где - это уже будет приятный бонус.

By: Chabster

Chabster — Fri, 25 Jan 2008 19:54:47 +0000

Строку в логе (из множества таких-же строк), порожденную конструкцией программы или наоборот, имея в сообщении имя файла, ревизию и номер строки кода? Это как в том анекдоте “Нужно найти X. Да вот же он, на доске!”.

By: Not a kernel guy

Not a kernel guy — Fri, 25 Jan 2008 17:41:17 +0000

Это лог некоего долгоиграющего процесса, который может завершиться либо успешно, либо с ошибкой. В лог в любом случае пишется ход процесса – что было сделано, в основном. Большая часть сообщений помечается тегом категории (info, warning, error). В моём случае этот процесс завершается невнятным сообщением «Что-то поломалось». Это практически буквальный перевод. Что именно поломалось – хз. Мне нужно быстро найти что именно поломалось.

Поиск по “Error”, “Fail”, “Failure”, “STATUS_[^S]” и т.д. не показывает ничего конкретного – находится лишь случайный мусор. Более того, сравнение двух логов: «хорошего» и «плохого», тоже ничего не даёт. В «плохом» просто отсутствует здоровенный кусок.

By: Mike Chaliy

Mike Chaliy — Fri, 25 Jan 2008 10:04:36 +0000

“простым текстовым поиском” - а как вы видите этот процес? Всмыле в логе как то должно сообщаться что сообщение об ОШИБКЕ, а не просто? Или как то-то по другому?

By: Vladislav Artukov

Vladislav Artukov — Thu, 24 Jan 2008 23:08:52 +0000

Еще интереснее получается, когда выполняется одно дело, а код пишет 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 и журналов не меньше. И некоторые из процессов кросс-зависимы.

Медвежуть!