Комментарии 15
Да, только при тотальной записи всего в лог возникают проблемы с безопасностью. Зачем злоумышленнику лезть в криптованную БД, когда в логах все есть?
Всего - да, но это на период отладки и внедрения.
Потом - только ошибок. Т.е GUI-шное приложение все сообщения об ошибках, которые выскакивают в виде диалоговых окошек паралельно пишет в лог.
Потом - только ошибок. Т.е GUI-шное приложение все сообщения об ошибках, которые выскакивают в виде диалоговых окошек паралельно пишет в лог.
Даже если на период отладки, зачем это давать пользователю.
На мой взгляд лучше (если софт клиент-серверный) на сеанс пользователя вести журнал его действий и событий (опять-таки "ваш" уровень детализации), в случае ошибки просто сообщать пользователю что случилось что-то не ладно с предложением обратиться к тех. поддержке (в данном случае к разработчику :-) ), а сам журнал отправляется разработчику (или в "клиент-сервере" в базе сохраняется).
По окончании сеанса мы удаляем журнал, если никаких проблем не было. ПОльзователю в случае чего достаточно сказать примерное время неполадки, чтобы разработчик мог выбрать из базы подходящие по времени журналы.
В случае отдельного приложения можно подготовить письмо с журналом (которое пользователю будет не удобно варимо, т.е. не понятно из-за формата) и предложить пользователю его отправить.
P.S. Хотя отчеты, которые нам предлагает распространенное ПО (например WinXP) мало кто отправляет, да и информации я думаю там не очень много полезной.
На мой взгляд лучше (если софт клиент-серверный) на сеанс пользователя вести журнал его действий и событий (опять-таки "ваш" уровень детализации), в случае ошибки просто сообщать пользователю что случилось что-то не ладно с предложением обратиться к тех. поддержке (в данном случае к разработчику :-) ), а сам журнал отправляется разработчику (или в "клиент-сервере" в базе сохраняется).
По окончании сеанса мы удаляем журнал, если никаких проблем не было. ПОльзователю в случае чего достаточно сказать примерное время неполадки, чтобы разработчик мог выбрать из базы подходящие по времени журналы.
В случае отдельного приложения можно подготовить письмо с журналом (которое пользователю будет не удобно варимо, т.е. не понятно из-за формата) и предложить пользователю его отправить.
P.S. Хотя отчеты, которые нам предлагает распространенное ПО (например WinXP) мало кто отправляет, да и информации я думаю там не очень много полезной.
Зря вы так, там есть полезная информация.
Несколько раз перезагружался компьютер, и каждый раз WinXP предлагало отправить отчёт. Я думал так же, что это всё бесполезно. Но однажды согласился, отчёт ушёл, после чего открылся firefox с сайтом microsoft support, где мне сообщили, что моя проблема старая, и надо обновить драйвера видеокарты.
Несколько раз перезагружался компьютер, и каждый раз WinXP предлагало отправить отчёт. Я думал так же, что это всё бесполезно. Но однажды согласился, отчёт ушёл, после чего открылся firefox с сайтом microsoft support, где мне сообщили, что моя проблема старая, и надо обновить драйвера видеокарты.
Да согласен, только в общем это говорит в пользу моей мысли :-)
Но думаю такие решение уже не на одного разработчика.
Но думаю такие решение уже не на одного разработчика.
В некоторых случаях можно самостоятельно обнаружить место возникновения ошибки. И даже не надо никаких специальных новыков.
Александр Суховей написал автоматический скрипт для этого.
Анализ дампов памяти как метод борьбы с BSoD
У меня иногда компьютер сам перезагружается. OCA просто показывала что проблема с драйвером (неизвестно каким). Благодаря скрипту смог понять что это был драйвер ADSL-модема.
Александр Суховей написал автоматический скрипт для этого.
Анализ дампов памяти как метод борьбы с BSoD
У меня иногда компьютер сам перезагружается. OCA просто показывала что проблема с драйвером (неизвестно каким). Благодаря скрипту смог понять что это был драйвер ADSL-модема.
Эх... Однажды, давно, более 10 лет тому назад, когда еще программисты были Программистами, а не много мнящими о себе кодерами, я видал вот такое решение. Очень продуманное.
При ошибке все переменные (это было на FPD 2.6) писались в лог. И выдавалось единственное универсальное понятное всем сообщение.
Ошибка. Сообщите администратору.
Программа после этого не работала. Совсем.
И это было правильно, потому что это был банковский опердень.
Более надежной технологии (пока что) не встречалось. Обсуждение здесь, имхо, довольно неглубокое (пока что)...
При ошибке все переменные (это было на FPD 2.6) писались в лог. И выдавалось единственное универсальное понятное всем сообщение.
Ошибка. Сообщите администратору.
Программа после этого не работала. Совсем.
И это было правильно, потому что это был банковский опердень.
Более надежной технологии (пока что) не встречалось. Обсуждение здесь, имхо, довольно неглубокое (пока что)...
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
1) я не про те ошибки. прочитайте внимательнее. В статье принается случай что программист достаточно грамотен чтобы предусмотреть указанного вида ошибки.
2) допрос пользователя таким методом - самое худшее что можно предложить и используется от безисходности.
Пользователи - тоже люди и им абсолютно наплевать на все ваши тонкости так же как и програмеру на тонкости выпечки хлеба, литья стали и прочего.
2) допрос пользователя таким методом - самое худшее что можно предложить и используется от безисходности.
Пользователи - тоже люди и им абсолютно наплевать на все ваши тонкости так же как и програмеру на тонкости выпечки хлеба, литья стали и прочего.
НЛО прилетело и опубликовало эту надпись здесь
Хорошо. Давай на пальцах. :)
Допустим есть клиентская программа. Для ее работы надо сервер.
А у пользователя кабель перекушен.
Пользователь запускает программу, а она что делает? Сообщает пользователю об ошибке "не могу подключиться к серверу". Так вот это "ошибка", это не "bug" про который ты рассказываешь.
Вот именно про такого рода предусмотренные сообщения об ошибках и идет речь. Это не допущенные програмером ошибки, это ошибки возникающие в р-те некорекности окружающей среды. Вот их в лог и надо писать для дальнейших разборок - кто, когда, во сколько и что делал и что ему сообщила система.
А по поводу качества софта и ошибки возникающие от недостаточного тестирования - хочется конечно по правильному, но не всегда это возможно к сожалению :( Тогда приходиться тестировать на пользователях. Хоть и понимаешь что это не правильно. Тут я согласен.
Допустим есть клиентская программа. Для ее работы надо сервер.
А у пользователя кабель перекушен.
Пользователь запускает программу, а она что делает? Сообщает пользователю об ошибке "не могу подключиться к серверу". Так вот это "ошибка", это не "bug" про который ты рассказываешь.
Вот именно про такого рода предусмотренные сообщения об ошибках и идет речь. Это не допущенные програмером ошибки, это ошибки возникающие в р-те некорекности окружающей среды. Вот их в лог и надо писать для дальнейших разборок - кто, когда, во сколько и что делал и что ему сообщила система.
А по поводу качества софта и ошибки возникающие от недостаточного тестирования - хочется конечно по правильному, но не всегда это возможно к сожалению :( Тогда приходиться тестировать на пользователях. Хоть и понимаешь что это не правильно. Тут я согласен.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
[prog] Как облегчить мучения пользователей и себя пользователями