try ... except

← →
Separator © (2005-11-20 13:55) [0]

Что-то много нарду стало, считающих, что try ... except(finally) решение всех их проблем, что это защита от ввода пользователем неправильных параметров и т.д.

← →
GuAV © (2005-11-20 14:00) [1]

> Что-то много нарду стало, считающих, что try ...
> except(finally) решение всех их проблем

Кто сказал ?

> что это защита от ввода пользователем неправильных
> параметров и т.д.

Нет, защита - это поднятие исключение, а try ... except(finally) - это уже обработка ситуации неправильного ввода.

← →
Separator © (2005-11-20 14:06) [2]

Толи я от жизни отстал, то ли я многого не понимаю. Просто что-то меня зацепил этот пост http://delphimaster.net/view/2-1132428043/
Но я всегда считал, что чем меньше используешь try except, тем лучше. И когда можно обойтись без него, то обхожусь. Единственно, когда в критических местах ставлю try .. finally, для очищения ресурсов.

Просветите меня, правильно ли я поступаю или нет?

← →
Qwertykz (2005-11-20 14:26) [3]

Но в любом случае это помогает в некоторых случаях?

← →
default © (2005-11-20 14:27) [4]

ну а ты сам как думаешь лучше бороться с причиной или следствием?
путь без блоков try это путь борьбы с причиной, с ними -со следствием
когда не удаётся загасить причину приходиться бороться со след-ем и использовать блоки try всё зависит от задачи и от твоей головы

← →
default © (2005-11-20 14:37) [5]

перекрывай в потомке
procedure CreateParams(var Params: TCreateParams);

← →
default © (2005-11-20 14:37) [6]

мать, не туда:)

← →
Separator © (2005-11-20 14:57) [7]

Ну в общем то я так и думаю, но откуда появляются люди с уверенностью утверждающие, что путь try лучший?

← →
sniknik © (2005-11-20 14:58) [8]

default © (20.11.05 14:27) [4]
ну это не совсем борьбы со следствием, это реакция на него. (борьба была бы если бы везде пустышки try ... except {nothing} end; стояли..)

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

к примеру предугадайка... ;)

ADOConnection1.Close;
ADOConnection1.ConnectionText:= Edit1.Text;

ADODataSet1.CommandText:= Edit2.Text;
ADODataSet1.Open;
...
получится заранее (только все варианты и чтоб правильно без ошибок), сам лично тебе памятник при жизни поставлю ;о)).

← →
default © (2005-11-20 14:59) [9]

Separator © (20.11.05 14:57) [7]
они тебе это доказали?:)нет!у тебя есть основания избрать другой путь, они не дали тебе оснований для пересмотра твоего пути так что пока можешь не беспокоиться;)

← →
sniknik © (2005-11-20 15:00) [10]

Separator © (20.11.05 14:57) [7]
в обшем ничего не бывает, давай конкретный случай, и будем разбирать, что для него будет лучше.

Исключительные ситуации надо употреблять по делу. А именно - тогда, когда вы не знаете какая ошибка может произойти в вашем коде. Или код сторонний и его апи предусматривает исключения. Если можно разрулить ситуацию без исключений, то лучше так и сделать.
Беда исключений в том, что они сразу сворачивают стек до обработчика. И возникает неочевидное поведение (напр. вы не предусмотрели такой порядок вызова деструкторов). Потому в стеке вызовов надо как можно ближе размещать обработчик и место возбуждения исключения. (имхо)

sniknik © (20.11.05 14:58) [8]
согласен, заметьте я сказал что когда нельзя устранить причину тогда блоки try никакого проиворечия:) когда можно и целесообразно устранить - устраняем причину, если нельзя устранить или нецелесообразно устранять(например, из-за большой сложности) то используем try

если считать за конкретику
Separator © (20.11.05 08:40) [13]
из ссылки.
> .... одно иг правильных решений:

то 2 дырки ты там допустил (чего не случилось бы при решении с try except)

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

> sniknik © (20.11.05 15:18) [13]

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

try ... except Найти похожие ветки