Использование "пустых" try .. except

← →
Palladin © (2006-12-08 23:18) [40]

там где оно всплывет, а именно при первом обращении к listbox1
все ясно и понятно

← →
Kerk © (2006-12-08 23:20) [41]

> [40] Palladin © (08.12.06 23:18)

Вместо Access violation впиши туда любой понравившийся эксепшн

← →
Leonid Troyanovsky © (2006-12-08 23:26) [42]

> Piter © (08.12.06 23:10) [33]

> P.S. Итог: да, в большинстве (подавляющем) случаев в except
> надо писать, но не всегда. Когда ты четко понимаешь, что
> ты делаешь - можно и пустым оставлять.

А вот ассоциировать себя с обработчиком исключений
N-го уровня не надо.

Бо, чревато.
Бо, чревато.
Чревато, бо.

--
Regards, LVT.

← →
Palladin © (2006-12-08 23:28) [43]

> [41] Kerk ©

какой именно?

← →
Kerk © (2006-12-08 23:28) [44]

> [43] Palladin © (08.12.06 23:28)

Любой. Out of memory или что угодно что может произойти

← →
Palladin © (2006-12-08 23:30) [45]

> [41] Kerk ©

ты пойми, это не понятие заглушки от любой ошибки, это подавление возмущения на которое нам наплеваит...

> [42] Leonid Troyanovsky ©

ты хочешь сказать что
try
v/0;
try
loadfrom
except
end
except
handle
end

куда то денет div by zero?

← →
Palladin © (2006-12-08 23:31) [46]

> [44] Kerk ©

см 45

← →
Anatoly Podgoretsky © (2006-12-08 23:31) [47]

> Piter (08.12.2006 23:15:37) [37]

> что такое отладочная переменная? Просто отфонарная, которая инициализируется только в этом except?

Которая позволяет увидеть реальное сообщение об ошибке, а не скрыть его.

← →
Palladin © (2006-12-08 23:32) [48]

> [47] Anatoly Podgoretsky ©

тоже 45

← →
Anatoly Podgoretsky © (2006-12-08 23:32) [49]

> Kerk (08.12.2006 23:16:39) [39]

Адептам подобного доказать не удастся, ну и пусть долбаются.

← →
Anatoly Podgoretsky © (2006-12-08 23:33) [50]

> Palladin (08.12.2006 23:18:40) [40]

Оно нигде не всплывет, оно окончательно спрятано.

← →
Leonid Troyanovsky © (2006-12-08 23:34) [51]

> Palladin © (08.12.06 23:30) [45]

> > [42] Leonid Troyanovsky ©

> ты хочешь сказать что

И ассоциировать себя с обработчиком ошибок
N+1 уровня тоже не надо.

--
Regards, LVT.

← →
Anatoly Podgoretsky © (2006-12-08 23:39) [52]

> Palladin (08.12.2006 23:30:45) [45]

Конечно, в данном случае исключения не будет.

← →
Anatoly Podgoretsky © (2006-12-08 23:40) [53]

> Leonid Troyanovsky (08.12.2006 23:34:51) [51]

И передергивать, тем более что пример то кривой :-)

← →
Palladin © (2006-12-08 23:42) [54]

ерундистику нести прекращайте, никто никого не принуждает действовать так при любом удобном случае.

к розетке можно руками прикасаться?
нет кончено!
а если она обесточена? вы соврали, я прикоснулся и ничего не произошло!..

смысл в том что, если человек знает, что делает и уверен в последствиях, другие, кто будут ему чего то там рассказывать про последствия, будут восприняты не совсем адекватными теоретиками и далеко посланы.

← →
Palladin © (2006-12-08 23:43) [55]

что то слегка запутано, но смысл понятен :)

← →
Gero © (2006-12-08 23:45) [56]

> [54] Palladin © (08.12.06 23:42)
> смысл в том что, если человек знает, что делает и уверен
> в последствиях

Часто ли такое бывает?

← →
Leonid Troyanovsky © (2006-12-09 00:06) [57]

> Anatoly Podgoretsky © (08.12.06 23:40) [53]

> И передергивать, тем более что пример то кривой :-)

Конечно, крив.

Сокрытие ошибок, вообще-то, есть заблуждение.
Т.е., скрывать исключения это - ошибочно.

Ну, а пытаться скрыть заблуждения - также ошибочно.
Хотя, это - уже личное дело каждого :)

--
Regards, LVT.

← →
Gero © (2006-12-09 00:08) [58]

> [57] Leonid Troyanovsky © (09.12.06 00:06)
> Сокрытие ошибок, вообще-то, есть заблуждение.
> Т.е., скрывать исключения это - ошибочно.

Смотря что понимать под словом «скрывать». Надеюсь, вы не станете говорить, что все ошибки нужно показывать пользователю.

← →
Anatoly Podgoretsky © (2006-12-09 00:09) [59]

> Leonid Troyanovsky (09.12.2006 0:06:57) [57]

Кривой он потому, что ошибки деления на 0 просто не будет, вне зависимости есть блок или нет.

← →
Anatoly Podgoretsky © (2006-12-09 00:10) [60]

> Gero (09.12.2006 0:08:58) [58]

Ну этого никто не утверждал.

← →
Eraser © (2006-12-09 00:10) [61]

> [57] Leonid Troyanovsky © (09.12.06 00:06)

> Сокрытие ошибок, вообще-то, есть заблуждение.
> Т.е., скрывать исключения это - ошибочно.

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

← →
Anatoly Podgoretsky © (2006-12-09 00:12) [62]

> Eraser (09.12.2006 0:10:01) [61]

Так никто этого и не утверждает, речь только про конструкцию except end

← →
Leonid Troyanovsky © (2006-12-09 00:29) [63]

> Anatoly Podgoretsky © (09.12.06 00:09) [59]

Да, конечно.
Необоснованная с моей стороны попытка
расширенного толкования, sorry.

Хотя, в приведенном коде были и другие камни.

--
Regards, LVT.

← →
Anatoly Podgoretsky © (2006-12-09 00:31) [64]

> Leonid Troyanovsky (09.12.2006 0:29:03) [63]

Я к тому, что ему стоило привести хотя бы рабочий пример.

← →
Anatoly Podgoretsky © (2006-12-09 00:34) [65]

> Anatoly Podgoretsky (09.12.2006 0:31:04) [64]

Сообственно дело даже не в ошибке, а то что пример не по делу.
Здесь обсуждается только один момент, это именно пустой блок и ничего более, остальное пристегивать к этому совсем ни к чему.

← →
Leonid Troyanovsky © (2006-12-09 00:35) [66]

> Gero © (09.12.06 00:08) [58]

> Смотря что понимать под словом «скрывать». Надеюсь, вы не
> станете говорить, что все ошибки нужно показывать пользователю.

Ошибки надо показывать допустившему оные, IMHO.
Пользователю, разработчику и т.д., вплоть до здешних обитателей.

--
Regards, LVT.

← →
vuk © (2006-12-09 00:45) [67]

to Piter © (08.12.06 21:26) [12]:
>представьте, что это не EXE-программа, а готовый компонент, который
>внутри себя использует ListBox. Компонент не должен вести логов.
Насчет логов - это личное дело компонента. Но вот чего компонент делать не должен, так это глушить исключения. Иначе потом ошибки замучаетесь ловить.

← →
Petr V. Abramov © (2006-12-09 00:45) [68]

> Leonid Troyanovsky © (09.12.06 00:35) [66]
точно. пусть она вылезет, и юзер завопит, и лет через 10 она будет исправлена. чем будет копиться отношение "ошибок нет, но гавно полное........2

> Eraser © (09.12.06 00:10) [61]

> исключение - это не всегда ошибка, бывает, что это вполне
> ожидаемы результат. но на любое исключение должна быть какая-
> то реакция, пусть и внешне незаметная.

На самом деле оный принцип формулируется проще:
не знаешь, как обработать возникшее исключение -
пропусти его.
Возможно, что на следующем уровне его обработают
как положено.

Ну, а если - везде нет, то, видимо, оному приложению
и не стоит далее работать.

--
Regards, LVT.

> Petr V. Abramov © (09.12.06 00:45) [68]

> точно. пусть она вылезет, и юзер завопит, и лет через 10
> она будет исправлена.

Если разработчик узнает о своих ошибках только от юзера,
то это хреновый разработчик.

Или это хреновые юзеры (и их руководители) готовые
терпеть это 10 лет.

--
Regards, LVT.

> Piter © (08.12.06 21:02)
>
> Была тут ветка, где возник некоторый спор по поводу допустимости
> использования пустых блоков try .. except.

Веток было более одной. У меня на них "собачий нюх", поскольку несколько раз "напарывался" на грабли подложенные кем-то ещё.
Моё скромное имхо - пустой блок except можно ставить только:
1. Будучи полностью уверенным, что данное исключение никак и никогда не приведёт к сбою программы. (А это скорее исключение, чем правило).
2. Если это не в компоненте. Используя пустой блок в компоненте, "The Gods Themselves Contains In Vain" © Isaak Asimov

> [66] Leonid Troyanovsky © (09.12.06 00:35)
> Ошибки надо показывать допустившему оные, IMHO.

Правильно. Юзер не допускает ошибок. От этого и следует плясать.

> [70] Leonid Troyanovsky © (09.12.06 00:54)
> Если разработчик узнает о своих ошибках только от юзера,
> то это хреновый разработчик.

От юзера по-любому будет узнавать, каким бы хорошим не был.

Gero © (08.12.06 23:16) [38]
Речь не о никогда, но в 99% случаев лучше бы написать

полностью согласен.

Kerk © (08.12.06 23:16) [39]
Произойдет здесь какое-нибудь не файл_не_найден, а эксесс виолейшн... и будешь потом искать где

а вот AV здесь не должен быть по определению, это уже косяк в сторону реализации метода компонента TListBox.

Palladin © (08.12.06 23:42) [54]
к розетке можно руками прикасаться?
нет кончено!
а если она обесточена? вы соврали, я прикоснулся и ничего не произошло!..

согласен! Хороший пример.

Если человек ничего не знает об электричестве, да, это постулат - к розетке прикасаться нельзя. Но если он понимает что откуда и зачем - то можно. НО - не всегда.

← →
ИА (2006-12-09 05:47) [74]

Ничего страшного в игнорировании ошибки в каждом отдельно взятом случае нет. Плохо когда это становится стилем. В программировании, уж простите за банальность, практически нет твердых правил без исключений. В данном случае мы и имеем такое исключение, поэтому не стои спорить о том, что надо делать в except, пробрасывать ошибку, писать ее в лог или игнорировать - примеров можно найти на все случаи.

Недавно попался мне проект. Все обращения к базе были обрамлены в try {} catch {} Разработчики так поступили так как сдавать было пора, а все валилось. Намучился я с отладкой и исправлением.

> Вамже уже сказали, что современные IDE позволяют исключения
> дебагером ловить, не надо никуда ничего ставить, они и так
> отобразятся в run-time

У пользователя наверняка установлена современная IDE и он от нечего делать ловит исключиния с помощью дебага.

В примере из [0] действительно можно оставить except пустым. Программа от этого скорее всего валиться не будет. Но этого даже в таком простом случае не есть гуд. Что мешает выполнить проверку существавания файла "default.m3u" перед загрузкой в ListBox1? Это гораздо лучше, чем необоснованное гашение исключений.

В некоторых редких случаях наличие try..except действительно обязательно. В здесь - не тот случай.

А в общем для обработки любых исключений полезно использовать обработчик ApplicationEvents.OnException. И здесь уже решать, стоит ли показывать исключение пользователю, и записывать ли информацию об возникшем исключении в лог. Можно даже разработать собственное окошко с ТМемо, в котором отображать информацию об ошибке. Можно формировать Bug Report и много других полезностей.

Нельзя заменять текст исключения своим текстом с измененным смыслом.

И еще рекомендации от меня:
При перехвате и регенерации исключения полезно к тексту исключения добавлять имя функции, в которой оно было перехвачено:

procedure MyProc; begin try ... except on E: Exception do raise Exception.Create(E.Message + " -> procedure MyProc"); end; end;

После таких нехитрых действий отлаживать программу - просто сказка (особенно, если Bug Report пришел от пользователя вашей программы, не догадавшегося поставить у себя современную IDE).

Loginov Dmitry © (09.12.06 9:33) [76]
Что мешает выполнить проверку существавания файла "default.m3u"

Логика такая загрузки файл-листа!
Ну давайте перепишем:

if FileExist(FileName) then try ListBox1.Items.LoadFromFile(FileName); except end;

что, большой смысл в этом?

> что, большой смысл в этом?
в этом нет, а вот в таком
try ListBox1.Items.LoadFromFile(FileName); except ListBox1.Clear; + сообщение/логирование, почему не удалось загрузить end;
есть, и вполне определенный... смотря конечно какая логика приложения, а то получается юзер тыкает тыкает в кнопку загрузки чегото (плейлиста там вроде у тебя) и ничего не происходит... бесполезная кнопка какаято получается, вместо этого лучше увидеть что лист очистился и причину по которой не удалось загрузить новый.
а такие вот "тайны внутреннего поведения" когда чтото делается, что непонятно, но в итоге работает не так как ожидается, меня лично как пользователя раздражают.

и кстати 90% проблем в цто, причем самых "геморойных" именно с этим и связаны, разработчик уверен, что ошибку обрабатывать не надо/или наоборот надо "улучшить" перевести на понятный язык, блокирует ее/или вешает свою интерпретацию "переведенного" сообщения, и ловит в том месте другое исключение... незапланированное... - получаем неработающую программу от неизвестно какой причины.
это уже практикой подтверждено. (я тут уже рассказывал несколько "страшных" историй по этому поводу :), реальных историй)
к примеру, о незапланированности, вот я чтото не видел в показанном как твой ListBox1 создается (а это же может быть? ну то что ты его в рантайм создаешь), в итоге ты скрыл AV при первом обращении (а создать просто забыл когда переделывал с лежащего на форме на создаваемый), при втором третьем обращении ты его также поймаешь... но вот беда там у тебя будут другие действия, и в них ты тоже уверен... и повесил другое сообщение, ListBox1 это уже будет только косвенно участвовать, естественно ошибку повесишь по действию, и это будет совершенно не та ошибка ...
в общем фигни можно всякой придумать, от такой идеологии.

а вообще обсуждение бредовое, ты вырвал маленький кусочек из контекста и пытаешься отстоять его правильность... хотя в целом он может означать разные веши, ну совсем разные, в зависимости от логики...

> Александр Иванов (09.12.2006 7:49:15) [75]

И тоже самое говорили, что все нормально, ошибки здесь не может быть, только нужная, которую можно скрыть.

> Loginov Dmitry (09.12.2006 9:33:16) [76]

> Что мешает выполнить проверку существавания файла "default.m3u" перед загрузкой в ListBox1? Это гораздо лучше, чем необоснованное гашение исключений.

Наличие файла не спасает от исключения

Использование "пустых" try .. except Найти похожие ветки