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

← →
Piter © (2006-12-08 21:02) [0]

Была тут ветка, где возник некоторый спор по поводу допустимости использования пустых блоков try .. except. Я придерживаюсь мнения, что в некоторых случаях это вполне нормально. Один мой оппонент придерживался обратного мнения, правда как всегда быстро срулил со словами, что со мной бесполезно спорить, даже не вникая в суть моих примеров :)

Но тут в очередной раз возникла ситуация, когда я оставил пустым try .. except, это что-то вроде того:

try ListBox1.Items.LoadFromFile("default.m3u"); except end;

Правда, у того же WinAmp"а формат немного другой, там не одна строка на одну композицию, но опять же - не в этом дело.

Что в этом примере не так? Я загружаю плейлист по-умолчанию, если допустим нет такого файла - не загрузится, ну и что, останется пустым. Можно вручную будет добавлять треки. Просто погашение возможного исключения.

← →
Palladin © (2006-12-08 21:04) [1]

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

← →
TUser © (2006-12-08 21:05) [2]

Я бы писАл так
try
...
except
on E:ХорошаОшибка do;

... else raise
end;

← →
Kerk © (2006-12-08 21:05) [3]

И как юзер догадается - файл пустой или его нет?

← →
вв © (2006-12-08 21:06) [4]

А можно мессаджбокс с рекламой телепатора продвинуть

← →
TUser © (2006-12-08 21:06) [5]

... но в случае с сущестованием файла пишу
if FileExists() then ...

← →
Anatoly Podgoretsky © (2006-12-08 21:07) [6]

> Piter (08.12.2006 21:02:00) [0]

try
ListBox1.Items.LoadFromFile("default.m3u");
except
Log;
end;

← →
Gero © (2006-12-08 21:14) [7]

В случае необязательности кода в блоке try ничего плохого в пустые except-ах нет. Ну не прокатило — и фиг с ним, нам даже не нужно знать, почему.
Хотя в таких случаях можно, например, в лог писать. Будет очень правильно и все каноны соблюдены.

← →
Gero © (2006-12-08 21:15) [8]

> [5] TUser © (08.12.06 21:06)

Это не всегда будет правильнее, зависит от задачи.

← →
Gero © (2006-12-08 21:15) [9]

> [6] Anatoly Podgoretsky © (08.12.06 21:07)

Да, я о том же.

← →
MikePetrichenko © (2006-12-08 21:24) [10]

> try
> ListBox1.Items.LoadFromFile("default.m3u");
> except
> Log;
> end;

Вот вы любите усложнить задачу.
Я очень часто использую
try
except end; Ну не нужно мне это исключение. Ну не получилось и ладно. И логи мне не нужны, потому как я ОЖИДАЮ эту ошибку и знаю что она рано или поздно случится. Вот живой пример. Переменная TDateTime. Она может быть 0 а может и не быть 0 (дата есть). При приобразовании в троку будет исключение. Но у меня строка до преобразования уже пустая. Нафига мне еще что-то обрабатывать. Получилось ну и отлично. Вывели отформатированные дату и время. Не получилось. Тоже не велика беда. Вывели пустую строку.

← →
Anatoly Podgoretsky © (2006-12-08 21:26) [11]

> Palladin (08.12.2006 21:04:01) [1]

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

except
on E:Exception do begin
ErrorMsg := E.Message;
// Log();
end;
end;

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

← →
Piter © (2006-12-08 21:26) [12]

Kerk © (08.12.06 21:05) [3]
И как юзер догадается - файл пустой или его нет?

а зачем ему это знать? Например, ты сформировал плейлист - он у тебя при загрузке есть. А потом ты удалил этот файл - при загрузке у тебя пустой плейлист. Что же теперь?

Такая же идеология у каких-нибудь INI-файлов, ты же не выдаешь предупреждение каждый раз, когда в INI отсутствует нужный параметр? Файла INI и вообще может не быть, просто грузишь константы по дефолту, если это возможно.

Так вот тут действие по дефолту - пустой файл-лист, так он и есть пустой при создании, поэтому ничего в except предпринимать не имеет смысла.

Anatoly Podgoretsky © (08.12.06 21:07) [6]
try
ListBox1.Items.LoadFromFile("default.m3u");
except
Log;
end;

вы уже фигней маетесь. Сейчас начнете рассказывать, что в каждой программе должен быть класс по ведению логов, и ПОЭТОМУ except никак не может пустовать.

А в моей программе нету вот логов. Да и не нужны они там. И вообще, логи - это отдельно, вы уже специально придумываете, ЧТО можно вставить в except в любом случае.

То есть логика из "а нужно ли что-то вставить в except" у вас трансформировалась в логику "чтобы блин такое придумать, чтобы вставить в except".

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

← →
Anatoly Podgoretsky © (2006-12-08 21:27) [13]

> TUser (08.12.2006 21:05:02) [2]

Или такой путь, если надо игнорировать ошибки только определенного класса, а вот использование

except
end

ничем не обосновано, благими намерениями строится дорога в ад.

← →
Piter © (2006-12-08 21:28) [14]

Anatoly Podgoretsky © (08.12.06 21:26) [11]
Можно поставить точку и узнать точную причину

а у меня в опциях delphi настроен вывод исключений дебагером.

← →
Anatoly Podgoretsky © (2006-12-08 21:29) [15]

> Gero (08.12.2006 21:14:07) [7]

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

← →
Anatoly Podgoretsky © (2006-12-08 21:31) [16]

> Gero (08.12.2006 21:15:09) [9]

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

Это я недавно прочувствовал на себе.

← →
Eraser © (2006-12-08 21:33) [17]

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

← →
Anatoly Podgoretsky © (2006-12-08 21:36) [18]

> MikePetrichenko (08.12.2006 21:24:10) [10]

С какой стати преобразование 0 вызовет исключение? Он отлично преобразуется в дату без каких либо исключений.

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

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

try
var := Convert
except
var := "";
end;

В чем проблема, кроме психологических заморочек.

← →
Anatoly Podgoretsky © (2006-12-08 21:38) [19]

> Piter (08.12.2006 21:26:12) [12]

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

← →
Palladin © (2006-12-08 21:40) [20]

> [11] Anatoly Podgoretsky ©

ну видимо потому что

Try
...
Except
{$ifdef debug}
WriteLog(GetExceptString);
{$endif}
End;

← →
Anatoly Podgoretsky © (2006-12-08 21:43) [21]

> Palladin (08.12.2006 21:40:20) [20]

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

← →
default © (2006-12-08 21:45) [22]

делать как в [11], конечно, не надо
современные визуальные среды с отладчика предоставляют подобные данные и без ручной работы

← →
Piter © (2006-12-08 22:35) [23]

Anatoly Podgoretsky © (08.12.06 21:36) [18]
try
var := Convert
except
var := "";
end;

В чем проблема, кроме психологических заморочек

в том, что значение "var" УЖЕ равно пустой строке, нафига перепресваивать?

// вот в этом месте кода значение "var" = "" try var := Convert except var := ""; end;

Ну и какой смысл в переприсвоении? Да, так можно сделать, ошибки нет, но ЗАЧЕМ?

Я рассуждаю на тему нужно / не нужно, вы же рассуждаете по-другому: "Поставить что-нибудь нужно обязательно!!! Надо только придумать что".

Anatoly Podgoretsky © (08.12.06 21:38) [19]
Если ты не понял о чем речь, то лучше не открывать лог, тем более нападать.
Ну я уже давно не обращаю внимания на твои нападки

оно и видно, что не обращаете :)
Вы меня загипнотизировать хотите, каждый раз повторяя, что не обращаете внимания на мои нападки или чтобы самому в это поверить? :) :) :)

Anatoly Podgoretsky © (08.12.06 21:43) [21]
важно что бы блок не был пустым

это важно только для того, чтобы Анатолий Подгорецкий был прав.

не надо в except пихать абы что, лишь бы ОН БЫЛ НЕ ПУСТОЙ. Если ты четко понимаешь, зачем это и для чего - можно и оставить пустым. Если понимаешь.

default © (08.12.06 21:45) [22]
делать как в [11], конечно, не надо
современные визуальные среды с отладчика предоставляют подобные данные и без ручной работы

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

Можно даже присвоить какой-нибудь введенной переменной какое-нибудь значение, пофигу что оптимизатор все равно выкинет этот блог, главное не оставлять except пустым...

← →
Kerk © (2006-12-08 22:42) [24]

> // вот в этом месте кода значение "var" = ""
> try
> var := Convert
> except
> var := "";
> end;
>
> Ну и какой смысл в переприсвоении? Да, так можно сделать,
> ошибки нет, но ЗАЧЕМ?

Никто ничего не переприсваивает

А вот тут переприсваивание:
var := ""; try var := Convert except end;

← →
Anatoly Podgoretsky © (2006-12-08 22:43) [25]

> Piter (08.12.2006 22:35:23) [23]

> Вы меня загипнотизировать хотите, каждый раз повторяя, что не обращаете внимания на мои нападки или чтобы самому в это поверить? :) :) :)

Это мантра для тебя.

← →
Anatoly Podgoretsky © (2006-12-08 22:44) [26]

> Piter (08.12.2006 22:35:23) [23]

// вот в этом месте кода значение "var" = ""

А почему в этом месте он пустой?
Всегда пустой? А почему, а если не пустой, а у меня гарантия.

← →
Petr V. Abramov © (2006-12-08 22:45) [27]

try
ListBox1.Items.LoadFromFile("default.m3u");
except
Log;
end;

вот из-за таких подходов и кодеров не хватает. Не заму...ся на каждую ситуацию так писать? Не лучше ли ОДИН раз потрудиться сделать запись в лог, например, в application.onexception

> существует много других случаев когда нужно просто проигнорировать
> исключение, бо последующие действия никак от нее него зависят...
существует, но редко. поэтому, ИМХО, должно считаться дурным тоном, почти как goto, которое тоже иногда ну очень полезно. ну очень иногда :)

← →
Anatoly Podgoretsky © (2006-12-08 22:45) [28]

> Piter (08.12.2006 22:35:23) [23]

Кстати я смотрю ты уже иногда и try except начал пользоваться, это у прогресс, осталось еще немного поднапряться

← →
Anatoly Podgoretsky © (2006-12-08 22:47) [29]

> Kerk (08.12.2006 22:42:24) [24]

Чистой воды переприсвоение, ну лишь бы except пустым оставить.

← →
Gero © (2006-12-08 23:04) [30]

> [23] Piter © (08.12.06 22:35)

Еще раз говорю, все зависит от задачи.
Предположим, у пользователя есть файл default.m3u, он видит его, но программа его не загружает. Притом программа знает почему его не удалось загрузить. Но молчит. Он пишет в саппорт — и как саппорту определить, в чем же проблема?
Так вот, если это записать в лог, достаточно посмотреть лог и определить, что же произошло: нет прав для чтения файла, файл заблокирован другим процессом, а может просто указан относительный путь, а текущий каталог совсем не тот, что нужно, а может еще что. Не важно что, важно, что любая ошибка, неправильная работа при таком подходе может быть быстро исправлена, и не в момент разработки, а уже будучи установленной у пользователя.

← →
Gero © (2006-12-08 23:05) [31]

> [23] Piter © (08.12.06 22:35)

Или ты просто с Анатолием поспорить хочешь? Если да, то скажи, я не буду мешать.

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

> Gero (08.12.2006 23:05:31) [31]

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

← →
Piter © (2006-12-08 23:10) [33]

Anatoly Podgoretsky © (08.12.06 22:45) [28]
Кстати я смотрю ты уже иногда и try except начал пользоваться, это у прогресс, осталось еще немного поднапряться

а... левая уколка. Я except"ы писал, когда у вас еще бороды не было :) :) :)

А вот то, что вы начинаете копировать мой стиль разговора говорит о том, что сами придумать ничего не можете.

Так что 1:0 - слив засчитан, все свободны :)

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

← →
Anatoly Podgoretsky © (2006-12-08 23:13) [34]

> Piter (08.12.2006 23:10:33) [33]

> Я except"ы писал, когда у вас еще бороды не было :) :) :)

Неужели 60 лет назад?

> Так что 1:0 - слив засчитан, все свободны :)

так просто не отделаешься.

> Когда ты четко понимаешь, что ты делаешь - можно и пустым оставлять.

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

← →
Piter © (2006-12-08 23:13) [35]

Gero © (08.12.06 23:04) [30]
Еще раз говорю, все зависит от задачи

вот именно. Есть задачи, где не обязательно ставить :) Я вовсе не утверждаю, что в except НИКОГДА ничего не надо писать.

Засим и закончим :)

← →
Anatoly Podgoretsky © (2006-12-08 23:14) [36]

> Piter (08.12.2006 23:13:35) [35]

Как это закончим, мы еще не начинали, в понедельник придет подкрепление.

← →
Piter © (2006-12-08 23:15) [37]

Anatoly Podgoretsky © (08.12.06 23:13) [34]
Как минимальный уровень я указал использование отладочной переменной.

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

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

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

← →
Gero © (2006-12-08 23:16) [38]

> [35] Piter © (08.12.06 23:13)

Речь не о никогда, но в 99% случаев лучше бы написать.

← →
Kerk © (2006-12-08 23:16) [39]

try ListBox1.Items.LoadFromFile("default.m3u"); except end;

Произойдет здесь какое-нибудь не файл_не_найден, а эксесс виолейшн... и будешь потом искать где.

← →
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

← →
Leonid Troyanovsky © (2006-12-09 00:47) [69]

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

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

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

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

--
Regards, LVT.

← →
Leonid Troyanovsky © (2006-12-09 00:54) [70]

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

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

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

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

--
Regards, LVT.

← →
Германн © (2006-12-09 01:20) [71]

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

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

← →
Gero © (2006-12-09 01:32) [72]

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

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

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

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

← →
Piter © (2006-12-09 02:01) [73]

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, пробрасывать ошибку, писать ее в лог или игнорировать - примеров можно найти на все случаи.

← →
Александр Иванов © (2006-12-09 07:49) [75]

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

← →
Loginov Dmitry © (2006-12-09 09:33) [76]

> Вамже уже сказали, что современные 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).

← →
Piter © (2006-12-09 12:40) [77]

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

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

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

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

← →
sniknik © (2006-12-09 13:27) [78]

> что, большой смысл в этом?
в этом нет, а вот в таком
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? Это гораздо лучше, чем необоснованное гашение исключений.

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

> Piter (09.12.2006 12:40:17) [77]

Убивать за подобное, лучше из рогатки.

> Piter © (09.12.06 12:40) [77]

В ЭТОМ никакого смысла нет вообще.

А вот в ЭТОМ:
if FileExist(FileName) then ListBox1.Items.LoadFromFile(FileName);
смысл есть. Потому что если при чтении СУЩЕСТВУЮЩЕГО файла возникла ошибка, значит, что-то не так с этим файлом, с этим каталогом, с этим диском, с этой файловой системой, с этой Windows, с этой машиной и т.д. О чем юзера надо уведомить, а не прятать от него проблему.

Как видите, блок try-except в данном случае не только не требуется, но и даже вреден.

А если мы в этот пример вдумаемся, то увидим, что на самом деле это вовсе никакой не пример, а общий случай. Если в коде (на первый взгляд, вроде бы, даже и обоснованно) стоит пустой except, то это, как правило, означает, что проверку ситуации, которая ошибкой НЕ является надо сделать ДО выполнения данного куска, а try выкинуть совсем. Чтобы не маскировать им ошибки ДЕЙСТВИТЕЛЬНЫЕ.

Почему и говорят, что пустой except - плохой стиль. И это правильно.

> sniknik (09.12.2006 13:27:18) [78]

except
ListBox1.Clear;
+ сообщение/логирование, почему не удалось загрузить
end;

В данном случае в сам ListBox1 можно и вывести сообщение об ошибке. Даже логирование не требуется.

sniknik © (09.12.06 13:27) [78]
ListBox1.Clear;

я знаю, что ListBox уже и так пустой. Нужна эта строчка?

sniknik © (09.12.06 13:27) [78]
+ сообщение/логирование, почему не удалось загрузить

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

Юрий Зотов © (09.12.06 13:45) [82]
Потому что если при чтении СУЩЕСТВУЮЩЕГО файла возникла ошибка, значит, что-то не так с этим файлом, с этим каталогом, с этим диском, с этой файловой системой, с этой Windows, с этой машиной и т.д. О чем юзера надо уведомить

а почему именно к существованию вы прицепились? Файл может быть и заблокировак другой программой, тогда надо так:

if FileExist(FileName) then if PermissionRead(FileName) then ListBox1.Items.LoadFromFile(FileName);

так? Продолжая логику, мы дойдем до того, обработаем САМИ все возможные ситуации возникновения исключений. Нафига это надо?
Если уж мы собрались выдавать сообщения о неудачной загрузке, то тогда уж просто:

ListBox1.Items.LoadFromFile(FileName);

А если не собираемся ничего сообщать юзеру о неудачной загрузке, то:

try ListBox1.Items.LoadFromFile(FileName); except; end;

> [85] Piter © (09.12.06 14:22)
> А если не собираемся ничего сообщать юзеру о неудачной загрузке,
> то:

А это зря. Пользователи тоже встречаются упорные и любопытные — вот хотят они знать, почему их любовно составленный плейлист не грузится и все тут! :)

Ну, я как минимум всегда стараюсь такую конструкцию использовать:

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

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

> А если не собираемся ничего сообщать юзеру о неудачной загрузке

Вот тут в соседней ветка пример на похожую тему. Человек запускает инсталлятор, тот стартует, а через секунду тихо умирает.

Так и тут - не грузится файл, и все. И никаких сообщений. И сиди, чеши репу. Хоть обчешись. Отличный стиль программирования, да?

Piter © (09.12.06 14:17) [84]
> я знаю, что ListBox уже и так пустой. Нужна эта строчка?
откуда я знаю? это же твоя логика. но если ты "рубиш" глюки и если это действие делается юзером повторно то почему в нем не может быть частично (изза глюка) загруженного файла?
т.что скорее нужна чем нет.

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

почему не обратил внимание на последний абзац ([78])? конкретизация тебе неудобна? не будет темы, флуда, а будет разбор твоего кода...

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

sniknik © (09.12.06 14:34) [89]
> потому что предположили, что именно это ты и "скрываешь" забывая о другом. логично. т.к. не описано.
сорри, описано... и похоже понято именно так как написано.
> [0] Я загружаю плейлист по-умолчанию, если допустим нет такого файла

а если допустим есть, и я его 3 часа скурпулезно составлял, открываю... нет моих композиций, а файл есть... (???), но просто нет прав на его открытие (но я этого не увижу), а оно име молча пустой список.
хотя я в общем и сам буду виноват, не под тем юзером зашел, но -> программу в корзину, однозначно!

Юрий Зотов © (09.12.06 14:30) [88]
Так и тут - не грузится файл, и все. И никаких сообщений. И сиди, чеши репу. Хоть обчешись. Отличный стиль программирования, да?

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

А если файл удален - то ничего нету. И что - добавляйте вручную или как-то так. Этого файла мож и не должно быть. Операция не критична, это не нарушение коннекта к БД, без которой программа функционал теряет.

Удалось загрузить дефолтный файл-лист - хорошо. Не удалось - и фиг с ним.

sniknik © (09.12.06 14:45) [91]
хотя я в общем и сам буду виноват, не под тем юзером зашел, но -> программу в корзину, однозначно

мне даже интересно стало. У тебя WinAmp есть?

Насоставляй там плейлист, закрой программу. Удали этот временный файл-лист. При новой загрузке тебе WinAmp ошибку выдаст или просто пустой список?

у меня просто WinAmp"а сейчас нету.

> у меня просто WinAmp"а сейчас нету.
аналогично, и не нужен он мне.

> Насоставляй там плейлист, закрой программу. Удали этот временный файл-лист. При новой загрузке тебе WinAmp ошибку
> выдаст или просто пустой список?
тебе вообщето про другое тут пытаются сказать, чего ты усиленно отказываешься понимать... судя по всему специально.

т.к. отсутствие файла это как раз предсказанное и логически обоснованное действие по нему... но, то что твоей идеологией удаляются и другие глюки, но это ты сознательно глаза закрываешь. иначе бы составил другой тест.
типа. -
Насоставляй там плейлист, закрой программу. сделай этот файл-лист нечитаемым (бреда туда внести в блокноте/поставить в доступ ему запрет на чтение/открыть другой программой эксклюзивно, неважно лиш бы открытие было ошибочным). При новой загрузке тебе WinAmp ошибку или просто пустой список?
вот это нужно проверять, а не просто отсутствие, которое ты ровняеш со всем что вообще возможно при открытии (хотя и говоришь в некоторых постах что нет, но действуешь как будто это равнозначно).

и кстати WinAmp это не показатель, что бы он там не выдал...

> sniknik (09.12.2006 16:12:34) [94]

> чего ты усиленно отказываешься понимать... судя по всему специально.

Это не специально, у него старые проблемы с логикой.

sniknik © (09.12.06 16:12) [94]

заморочился, поставил WinAmp.

sniknik © (09.12.06 16:12) [94]
поставить в доступ ему запрет на чтение

ошибки не выдал

sniknik © (09.12.06 16:12) [94]
отсутствие файла

ошибки не выдал.

Единственная его реация - просто пустой плей-лист.
Собственно, я этого и ожидал.

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

WinAmp полностью оправдал мои надежды. Ну можно там со всякими FooBar поэкспериментировать, кому хочется.

Хотя естественно, всегда можно сказать:

sniknik © (09.12.06 16:12) [94]
и кстати WinAmp это не показатель, что бы он там не выдал...

а что, извините, показатель?

> Piter (09.12.2006 16:27:36) [96]

> а что, извините, показатель?

Питер показатель.

> поставить в доступ ему запрет на чтение
> ошибки не выдал
а блокнотом, при таком, его открывать выдает?

> а что, извините, показатель?
для своих програм, я, единственный и неповторимый показатель, и если я знаю что делая так, мне в случае чего после меньше проблем будет, то я так и сделаю.
WinAmp бесплатен? т.е. распространяется as is? если так то претензии пользователей не принимаются, ползуйся пока устраивает, а с меня в случае чего начальство взыщет...

sniknik © (09.12.06 16:44) [98]
а блокнотом, при таком, его открывать выдает?

а у блокнота показать файл ОСНОВНАЯ ФУНКЦИЯ. Ты меня обвиняешь в том, что я тебя не слушаю, а по-моему это ТЫ меня не слушаешь.

Понятное дело, что если программа не может выполнить свою ОСНОВНУЮ функцию - она пишет ошибку.

sniknik © (09.12.06 16:44) [98]
WinAmp бесплатен? т.е. распространяется as is? если так то претензии пользователей не принимаются, ползуйся пока устраивает, а с меня в случае чего начальство взыщет...

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

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

Не надо этого делать. Я говорил, что иногда. И как правильно тут кто-то заметил - зависит от задачи.

А ты начал сруливать куда-то уже вообще в дебри, "а у меня начальство, а оно вот строгое, а туда сюда, а блокнот выдает ошибку, а вот винда тоже выдаст ошибку, если не сможет прочитать системный файл..." и прочее... Как это относится к теме?

> а туда сюда, а блокнот выдает ошибку
вообщето я спросил только для того чтобы убедится что ты действительно запретил открытие, а не просто "ридонли" файлу поставил...
а ты тут таких выводов понаделал, страшно становится.

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

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

> Anatoly Podgoretsky © (08.12.06 21:36) [18]
> > MikePetrichenko (08.12.2006 21:24:10) [10]
>
> С какой стати преобразование 0 вызовет исключение? Он отлично
> преобразуется в дату без каких либо исключений.

Вот кусок из рекальной проги (Open и Next делается для IBQuery, который выше по коду):

try Open; while not Eof do begin FTask.Message.Files.AddObject(FieldByName("FILES_NAME").AsString, TObject(FieldByName("FILES_ID").AsInteger)); Next; end; except end;

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

Главное - поток должен работать и умереть по конкретным причинам. Дальнейшее испольнение программы никак не зависит от того будет здесь исключение или нет.

И логи мне тут нафиг не нужны.

> MikePetrichenko © (09.12.06 18:43) [101]

> Этот кусок кода выполняется в потоке. Мне абсолюно параллельно
> что там происходит.

- Вам действительно все пофигу?
- Все пофиг.
- Ну, а деньги?
- Не, деньги нам не пофиг.
- Дык, это ж непоследовательно(нелогично).
- А это нам пофиг.

--
Regards, LVT.

> Piter © (09.12.06 17:23) [99]

> Не надо этого делать. Я говорил, что иногда.

Этого достаточно.
Правильно же говорить - никогда.
Без всяких зависимостей и ограничений.

Все остальное - заблуждения.

--
Regards, LVT.

Я использую пустой try..except, например, при загрузке файла языка. Делается это в Form1Create. Если файла Language.txt в катклоге проги нет, то все по умолчанию на английском.
В случае с default.m3u я бы выдал ошибку, т.к. если файл заблокирован, то при закрытии проги плейлист не сохранится, об этом лучше предупреждать заранее.

> MikePetrichenko, код ничего не говорит. Почему параллельно?

> Вот кусок из рекальной проги (Open и Next делается для IBQuery, который выше по коду):
вот это "ближе к телу", но недостаточно, придется домысливать...

> Дальнейшее испольнение программы никак не зависит от того будет здесь исключение или нет.
если не зависит то сделай этот кусок завершенным, закрывай запрос после действий переноса, если не закрыл то предполагается используешь его дальше, а значит не настолько и пофиг.
и слишком долгая адресация (FTask.Message.Files), Files понятно типа TStrings (судя по AddObject с вполне определенными параметрами) Message это уже чтото свое (не помню такого обьекта со свойством Files типа TStrings/стринглист), а вот FTask это уже получается либо форма либо другой поток (к себе адресация не была бы такой длинной...). ну а если это так то... не упомянутая/не показанная синхронизация в потоке означает ее отсутствие. тогда понятно зачем тут этот пустой блок. валилось небось изредка от неизвестных причин? да?

а вообще если действительно "абсолютно параллельно что там происходит" то вообще выкини этот кусок из программы, сэкономь ресурсы, ускорь поток!
зачем делать чтото абсолютно ненужное?

> - Вам действительно все пофигу?
> - Все пофиг.
> - Ну, а деньги?
> - Не, деньги нам не пофиг.
> - Дык, это ж непоследовательно(нелогично).
> - А это нам пофиг.
>
> --
> Regards, LVT.

Это к чему? Или только что-бы что-то написать? Где у меня "все пофиг"?

> Неаппетитно какой-то.

Все тут пишут без опечаток?

Мдя... Народи лишьбы засветиться. По сему дискуссия бессмыслена

сам иногда пишу пиустые except"ы.
но готов признать, что это от лени.

> [56] Gero ©

довольно часто

2All
зачем путать:
1. дисциплину кодирования и осознование происходящего - оно вполне уживается вместе при знании дела
2. теорию и практику - в теории даже присвоение значения переменной нужно ставить под try... онож теория... недавно мой знакомый проводил опрос: кто нибудь обрабатывает ошибку нехватки памяти при ее захвате? все - нет. LVT конечно же каждый getmem и new блюдет и потом рассказывает пользователю, зачем и сколько ему понадобилось памяти и советует ему закрыть программы либо прикупить еще модулей... ага... хотелось бы в это верить, я думаю так оно и есть, по его возмущениям пустых обработчиков исключений...

> довольно часто
>
> 2All
> зачем путать:
> 1. дисциплину кодирования и осознование происходящего -
> оно вполне уживается вместе при знании дела
> 2. теорию и практику - в теории даже присвоение значения
> переменной нужно ставить под try... онож теория... недавно
> мой знакомый проводил опрос: кто нибудь обрабатывает ошибку
> нехватки памяти при ее захвате? все - нет. LVT конечно же
> каждый getmem и new блюдет и потом рассказывает пользователю,
> зачем и сколько ему понадобилось памяти и советует ему
> закрыть программы либо прикупить еще модулей... ага... хотелось
> бы в это верить, я думаю так оно и есть, по его возмущениям
> пустых обработчиков исключений...

А вот это поддерживаю. Во всем стоит знать меру. Да и вопрос целесообразности...

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