 | | | | |
Полный текст материала
Другие публикации автора: Александр Алексеев
Цитата или краткий комментарий: | «... Ошибки неизбежны, а совершать их – в природе человека. Поэтому к их возникновению нужно готовить себя заранее. Эта статья как раз и посвящена ошибкам, способам их обработки и диагностики. ...» |
Важно:- Страница предназначена для обсуждения материала, его содержания, полезности, соответствия действительности и так далее. Смысл не в разборке, а в приближении к истине :о) и пользе для всех.
- Любые другие сообщения или вопросы, а так же личные эмоции в адрес авторов и полемика, не относящаяся к теме обсуждаемого материала, будут удаляться без предупреждения авторов, дабы не мешать жителям нормально общаться.
- При голосовании учитывайте уровень, на который расчитан материал. "Интересность и полезность" имеет смысл оценивать относительно того, кому именно предназначался материал.
- Размер одного сообщений не должен превышать 5К. Если Вам нужно сказать больше, сделайте это за два раза. Или, что в данной ситуации правильнее, напишите свою статью.
Всегда легче осудить сделанное, нежели сделать самому. Поэтому, пожалуйста, соблюдайте правила Королевства и уважайте друг друга.
Добавить свое мнение.
| | | Содержит полезные и(или) интересные сведения | | [1] | 18 | 100% | | | | | Ничего особенно нового и интересного | | [2] | 0 | 0% | | | | | Написано неверно (обязательно укажите почему) | | [3] | 0 | 0% | |
Всего проголосовали: 18 | | | | Все понятно, материал читается легко | | [1] | 15 | 100% | | | | | Есть неясности в изложении | | [2] | 0 | 0% | | | | | Непонятно написано, трудно читается | | [3] | 0 | 0% | |
Всего проголосовали: 15 |
[Потоки (нити) Threads] [Отладчик] [Указатели, работа с памятью] [Операторы, синтаксис языка.] [Классы] [Жизненный цикл] [Исключения (exceptions)] [Структура VCL-приложения] [Конструктор/деструктор класса] [Настройка среды (IDE)] [Утечки памяти]
Отслеживать это обсуждение 
Всего сообщений: 3513-10-2012 08:00
03-06-2010 19:58| Фиг. 2 совершенно негодный в качестве иллюстрации описанных страшных ужасов. Девочка с ресепшена - да, вряд ли сможет сказать больше чем "там выскакивает какая-то ошибка". Программисту же ясно, что в строке N {00401A73-базовый адрес -> Find Error -> вуаля, модуль и строка} обнулился указатель и произошло это при обращении ко второму мемберу {00000008/SizeOf(LongWord) = 2; спекулирую, но очень типично}. Так что, фиг. 1 - символизирует, ибо, как максимум, сообщает о предстоящем допросе пользователя с целью выяснить, как же он такого добился; затруднения же с анализом фиг. 2, возможно, просто намекают разработчику на смену профессии. |
|
11-03-2010 02:58
15-02-2010 17:59| Спасибо, замечательная статья. |
|
20-05-2009 13:29Это скорей, пример, когда появление ошибки проблематично предупредить проверкой данных, поскольку она связана с реализацией конкретного механизма и его некорректным применением.
|
|
20-05-2009 10:46>>> Либо тщательно следить за списком указателей (что, правильно)
Хм... По-моему, именно так и никаких "либо".
>>> либо ловить AV.
>>> При этом, AV - ожидаемое событие, и даже не совсем ошибка.
Прочитал, и волосы на голове зашевелились ;-) Избаловала Вас Винда, не позволяя совершить фатальную ошибку. А вот если бы у Вас из-за неаккуратного программирования комп бы зависал (как это могло случиться при программировании под ДОС), то Вам бы тоже в голову не пришло использовать AV в качестве ожидаемого события. |
|
18-05-2009 21:33Очень полезный материал. Правда, обработка ошибок еще не уложилась...
Полезное упоминание, насчет "вольны делать что угодно" и доверенной зоне.
Периодически задаюсь вопросом, вставлять в некую функцию проверки или нет.
Регулярно оказыватся, что в одних местах проверка и так производится перед вызовом...
В других местах, вроде как не так удобно делать проверки.
Как результат - дублирование проверок.
Как выход - основная функция без проверок + функция-проверка (преобразование) данных.
Есть у меня такая функция:
function nzd(VariantVal : Variant; ErrValue : Double = 0.0) : Double;
begin
try
result:=VariantVal
except
result:=ErrValue
end;
end;
С точки зрения минимизации исключений... не комильфо. И с точки зрения отладки - может утомить сообщениями. В тот момент, ничего другого в голову не пришло. Зато работает.
Регулярно возникает желание проверить указатель на объект, есть там что или нет...
Всякие nil, assigned показывают только одно - был указатель присвоен, не был или уже сброшен мною же.
Там же где, особо надо - десять указателей и освобожденный объект - никак не поможет.
Либо тщательно следить за списком указателей (что, правильно), либо ловить AV.
При этом, AV - ожидаемое событие, и даже не совсем ошибка.
|
|
09-04-2009 06:28Весьма неплохо написана статья. Не хватает, на мой взгляд, описания стандартных функций, по получению данных из стека (или хотя бы упоминания, чтобы знать в какой стороне копать), потому что обсуждается только "сторонние компоненты" со словами "а чего мало -- можете дописать"...
Но для "усвояимости" -- надо перечитать еще разок... |
|
08-04-2009 08:26| уф, наконец-то дочитал... но, лучше поздно, чем никогда. Интересная и познавательная статья. Теперь нужно еще раз подробно просмотреть, чтобы закрепить материал |
|
29-03-2009 04:07Автору респект за статью! Очень редко встретишь столь
ценный материал со столь грамотным стилем изложения. СПАСИБО!
> Большинство тут занимаются тем, что хвалят друг друга.
здесь явно не тот случай! |
|
18-03-2009 02:03Хочу поблагодарить автора статьи за такой огромный, и главное, ценный материал, который он подготовил и предоставил совершенно по нашенски (безвозмездно).
Лично для меня эта статья - бомба, спасибо! |
|
16-03-2009 10:28Очень полезная статья. Спасибо!
Мне кажется вообще уже давно нужна такая книга по паттернам обработки ошибок, чтобы под рукой был систематизированный набор правил.
Небольшое пожелание по pdf версии. Если можно в будущих редакциях переоформить блоки кода более удобочитаемыми, например, чтобы комментарии не продолжались на последующих строках. |
|
02-03-2009 01:52| Хочу выразить благодарность автору. Лично мне эта статья (книга?) уже помогла правильно организовать обработку исключений в safecall методах. |
|
24-02-2009 02:17Поскольку задан очень высокий уровень материала, позволю себе попридираться :)
что не значит, что вы должны вызывать эту функцию в финальной версии "Не" можно потерять, особенно если она на другой строке, вообще я долго вникал всё-таки нужно её вызывать в финальной версии, или не нужно. Проще написать так ~ "Примечание: в финальной версии эту функцию вызывать не нужно".
Кроме того, пожелание на будущее (не сочтите за наглость): хотелось бы узнать особенности обработки ошибок в службах, например служба периодически находит в заданной папке файлы и добавляет записи в БД, файлы могут быть с неправильным форматом, отсутствовать сеть и т.п., ошибки не должны приводить к остановке, но кудато выводиться, только не на экран, Application.OnException использовать нельзя. |
|
24-02-2009 01:48>>> Ээээ... может быть имелось ввиду RAISE ... AT ...?
*листает хелп* Блин! Точн, raise at. Лишнее доказательстов редкости использования данной опции :D |
|
24-02-2009 01:39сообщение от автора материала >>> добавьте в текст про RAISE описание опции ON
Ээээ... может быть имелось ввиду RAISE ... AT ...? (делает пометку в блокноте) |
|
24-02-2009 01:03Хорошая "статья" ;-)
Конечно же, это не совсем статья, а, как тут уже замечено, больше напоминает книгу. И не только из-за объема, а из-за структуры. Статью, обычно, читаешь от корки дол корки целиком. Книги же я бегнло прочитываю, а потом детально изучаю те разделы, которые представляют особый интерес.
Очень порадовал стиль изложения, когда правильно излагаются серьезные вещи, но язык изложения легкий и живой (плюс разумное количество шуток). Зачет!
Александр! Если планируете дальше развивать и перерабатывать маетирал, то у меня социальный заказ: добавьте в текст про RAISE описание опции ON. К чему это приводит и зачем это надо. По-моему, вещь хоть и редакя (для прикладного программиста), но разобраться стоит. А в хелпе этому моменту не уделено достаточно внимания. |
|
23-02-2009 09:41bar:
Вы ничего не докажете. Большинство тут занимаются тем, что хвалят друг друга. Не спорю с тем, что мои статьи еще более далеки от совершенства. С другой стороны, человек, написавший такой объем в сочетании с красотой картинок чего-то стоит, но лично я статью не оценил :( Возможно, потому что не пытался вникнуть. |
|
23-02-2009 09:34To Ins:
Попробую подробнее пояснить свою позицию.
Во-первых, сам автор призывает, чтобы исключения были максимально информативными, и с этим я полностью согласен. Генерация невнятного исключения только дезориентирует программиста.
Во-вторых, проверка параметров, это в значительной степени миф. Обычно можно проверить только указатели на NULL (или NIL). Если функция может совершить полезную работу при нулевом значении указателя, это не является ошибочной ситуацией, а если нулевой указатель недопустим, то нужно, либо генерировать точное сообщение об этом и прекратить исполнение ее кода, либо вообще ничего не проверять, так как попытка обращения по такому указателю все равно приведет к генерации исключения.
|
|
23-02-2009 02:10А подход описанный в пункте 2.6.28. Если вызывающая сторона не выполняет контракт — вы вправе делать что угодно вообще вызывает недоумение.
Обеими руками поддерживаю подход, описанный в статье. В отлаженной программе не должно быть некоректных вызовов, и если при этом функция приведет к генерации исключения, то это сильно поможет найти в коде такой вызов и обезвредить его. Гораздо лучше, чем проигнорировать (или вернуть какой-то статус, который программист все равно забудет проверить) и получить ошибку совсем в другом месте непонятно из-за чего возникшую. И это в лучшем случае, в худшем же программист вообще не скоро может узнать, что у него в программе ошибка. А как известно, ошибка обнаруженная на стадии разработки, обходится в сотни раз дешевле, чем после того как продукт попадет к пользователям.
ЗЫ: Автору - зачет! Объем и качество проделанной работы - впечатляет! |
|
21-02-2009 13:53сообщение от автора материала >>> К сожалению 80% процентов статьи не соответствует заявленной теме, а посвящено отладке программ
Увы, ничего более путного мне в голову не пришло. |
|
21-02-2009 12:08Александр, я просто обалдел!
Честно, за раз всё прочесть не реально, но половину осилил! И много интересного узнал. Представляю, какой это труд. Я так думаю книга намечается? Если нет, то стоит подумать! |
|
21-02-2009 10:15К сожалению 80% процентов статьи не соответствует заявленной теме, а посвящено отладке программ (борьбе с программистскими ошибками).
Действительно полезными для неопытных программистов можно признать только несколько пунктов:
2.6.15. Не пытайтесь обрабатывать ошибки написания кода
2.6.25. Исключения — не всегда ошибки
и некоторые другие.
А подход описанный в пункте 2.6.28. Если вызывающая сторона не выполняет контракт — вы вправе делать что угодно вообще вызывает недоумение. |
|
21-02-2009 03:56| Спасибо! Поставлю качать на ночь :) |
|
21-02-2009 03:47
21-02-2009 01:35
20-02-2009 10:08| Сделайте, пожалуйста, статью одним файлом и в архиве (туда же и демо можно). Думаю, что в наших интернет-реалиях не у меня одного трудности с открытием такой объемной страницы. Спасибо. |
|
20-02-2009 08:18сообщение от автора материала >>> madExcept платен только для коммерческого использования. И стоимость его в таком случае чисто символическая
Да, честно говоря, я не очень знаком с madExcept - ставил один раз пощупать и поиграться. Но на сайте у них написано "you may use the non-commercial edition for 30 days of evaluation". Хотя да, лицензия с исходниками стоит $100 против $150 для EurekaLog.
А в общем и целом эти два продукта очень похожи. |
|
20-02-2009 08:02сообщение от автора материала У меня действительно есть планы на продолжение, но они больше с уклоном в практическую диагностику и отладку, чем в сторону уязвимостей и безопасности. |
|
20-02-2009 07:00
20-02-2009 06:16Браво! Отличнейший материал. Все сразу слету не осилил, думаю раза с третьего осилю все:)
Да, madExcept платен только для коммерческого использования. И стоимость его в таком случае чисто символическая |
|
20-02-2009 03:32| Очень редко бывают ситуации, когда приложение просто закрывается (вылетает) без всякого сообщения об ошибке Ну не так уж и редко, если дело касается Net. А вообще статья тянет на отдельную книгу, браво автору, читать всем. |
|
20-02-2009 01:34И всё-таки её опубликовали :) Спасибо людям, выложившим здесь статью. По себе знаю - такой большой материал проанализировать не так просто.
Спасибо Александру за само желание так подробно осветить проблему! Огромная работа.
Правда, Александр так и не согласился назвать этот текст книгой :) По мне, данный материал вполне можно опубликовать. |
|
20-02-2009 01:32| Фундаментальный труд. Читал взахлеб, но с первого раза не осилил. Возможно, стоило разбить на цикл статей. |
|
20-02-2009 00:29| Очень хорошая статья, даже я подчеркнул кое что для себя. Ценность в том, что все собрано в одном месте. Автору отлично. |
|
|
|
