Использование try finally и try except

← →
closer © (2003-11-28 20:42) [0]

Будут ли коректно работать конструкции try finally и try except если отключен модуль SysUtils в котором описаны классы исключений.

P.S.
Программа представляет из себя один dpr, без форм, т.к. необходим минимальный размер exe. А подключение SysUtils даёт значительный прирост "веса" exe.

← →
Юрий Зотов © (2003-11-28 20:44) [1]

Будут. Отключение SysUtils не отменяет самих исключений.

← →
Anatoly Podgoretsky © (2003-11-28 20:45) [2]

А проверить?

← →
closer © (2003-11-28 21:11) [3]

> А проверить?
Я себе не доверяю. :)

Насамом деле я не очень хорошо представляю каким образом работает этот механизм в Delphi или С++ (есть ли разница в его реализации на этих языках?).

Может кто-нибуть сможет помочь Internet-ресурсами по этому вопросу?

← →
Anatoly Podgoretsky © (2003-11-28 21:17) [4]

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

← →
Юрий Зотов © (2003-11-28 21:23) [5]

> closer © (28.11.03 21:11) [3]

Это механизм не столько языков, сколько самой системы (SEH - Structured Exception Handling). Описан в MSDN.

← →
Palladin © (2003-11-28 21:25) [6]

Механизм чего? Исключений или же нюансов подключения модулей?
Исключения - весчь системная и "raise", Exception и классы ExceptClass лишь оболочки/утилиты облегчающие обработку и вызов исключений в контексте Object Pascal.
Модули, единожды подключеные, включаются во всю программу.
Повторное указание в каком либо модуле например SysUtils просто открывает область видимости объектов, идентификаторов и типов, указанных в секции interface у SysUtils.

Например

Unit SubUnit1;
interface
uses
classes;

var
SL:TStringList;
implementation
...
end.

Unit MainUnit;
interface
uses
SubUnit1;
implementation

здесь доступен SL и все его методы, ибо компилятор знает что есть TStringList, но он (TStringList) не объявлен в области видимости у модуля MainUnit

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

← →
vuk © (2003-11-28 21:30) [7]

to Юрий Зотов:
Не соглашусь. Сам по себе try/except - именно языковой механизм и на SEH никак не завязан. Отключение же модуля SysUtils приведет к тому, что не будет возникать стандартных исключений.

← →
Юрий Зотов © (2003-11-28 22:06) [8]

> vuk

program Project1; {$APPTYPE CONSOLE } var A: word = 0; begin try A := 1 div A; finally WriteLn("finally"); end end.

Проходим отладчиком - writeln вызывается. Потом убираем try и еще раз проходим отладчиком - writeln не вызывается. Значит, в отношении finally Вы не правы.

ОК, теперь менеям finally на except и видим, что wrileln не вызывается. Добавляем SysUtils - вызывается. Значит, в отношении except Вы правы. Ответ, повидимому, надо искать где-то в недрах SysUtils.Initialization.

← →
Vuk © (2003-11-28 22:14) [9]

to Юрий Зотов:
>Значит, в отношении finally Вы не правы.
Хде я не прав? finally будет вызываться, что называется, по любому - было исключение или его не было. Что и наблюдается.

← →
Юрий Зотов © (2003-11-28 22:21) [10]

> Vuk © (28.11.03 22:14) [9]
> finally будет вызываться, что называется, по любому - было
> исключение или его не было
В том то и дело - вызывается, даже если было. То есть, обработка исключений все-таки работает. Заход в finally при возникновении исключения - разве это не есть ТОЖЕ обработка исключения?

← →
vuk © (2003-11-28 22:52) [11]

Ну да. Только дело не в SysUtils, а в system и startup коде RTL.

← →
Бином Ньютоныч (2003-11-28 23:32) [12]

>vuk © (28.11.03 21:30) [7]
>Не соглашусь. Сам по себе try/except - именно языковой механизм и на SEH никак не завязан. Отключение же модуля SysUtils приведет к тому, что не будет возникать стандартных исключений.

Как же не завязан? Пишем try - компилятор загоняет в стек точку перехода на "общий" обработчик исключений, а вершину стека сохраняет в TLS. Будет исключение - на него и перейдет обработка, что и обеспечивает SEH. И этот "общий" обработчик проверяет, указаны ли "частные" обработчики ошибок. И если нет, что и происходит без Sysutils или если свои не укажешь, то возвращается 1 и система валит процесс. Вроде примерно так, а?

← →
closer © (2003-11-30 00:47) [13]

Кто-нибудь хочет что то-нибудь добавить?

P.S.
Если "нет" я подведу итог.

← →
марсианин (2003-11-30 03:52) [14]

try-finally без СисУтилс работать будет -100%
а в случае try-except

try
X := Y/Z;
except
on EZeroDivide do .......;
end;

так вот оно бы работало, если бы после не требовалось поставить EZeroDivide или что-то еще.. вот было бы как в Сях exception по коду вылавливать.. может и здесь так можно? без всяких классов.. я не в курсе..

← →
марсианин (2003-11-30 04:20) [15]

забираю свои слова обратно:
если закомментировать SysUtils, этот код ведет себя совсем по-другому (у меня Делфи 5)

program Project2; {$APPTYPE CONSOLE} uses SysUtils, Windows; var x,y,z:Single; begin x := 0; y := 1; z := 0; try try x := y/z; except on TObject do // Exception begin writeln("error"); MessageBeep(DWORD(-1)); end; end;//*) finally writeln("finally x=",x); ReadLn; end; end.

← →
Nikolay M. © (2003-11-30 11:41) [16]

В продолжение темы.

> Юрий Зотов © (28.11.03 22:21) [10]
> vuk © (28.11.03 22:52) [11]
> Бином Ньютоныч (28.11.03 23:32) [12]

С месяц назад тоже озаботился этим вопросом - каким образом реализованы обработчики исключений и можно ли в Дельфи (или в любой другой среде) обойтись без try..except или аналогов. Но в MSDN все, что касается SEH, крутится вокруг __try и __catch. Неужели, если хотим избавиться от try..except, нужно руками реализовывать [12]?

← →
Бином Ньютоныч (2003-11-30 14:52) [17]

>Nikolay M. © (30.11.03 11:41) [16]
> Неужели, если хотим избавиться от try..except, нужно руками реализовывать [12]?

Канэчна, дарагой:) От SEH приходит флаг исключения в структуре PExceptionRecord, который нужно разруливать, иного не дано. Не, если делать чисто raise EMyException.create..., где EMyException = class(TObject), то достаточно указать ExceptProc в System, но при этом системные исключения типа деления на ноль и т.п. завалят прогу. А вообще-то здесь смысл чиста познавательный. Ну делал я, сэкономил кил 20-30... оно надо?

Подведу итог (поправте если я где-то ошибся):
1. Конструкцию try finally можно использовать не подключая модуль SysUtils.
2. Конструкция try except корректно работает только при подключении модуля SysUtils. Это связано с тем, что в этом модуле объявлены процедуры которые выполняются при возникновении исключений (выводят окошки с ошибками, вызывают классы исключений).

> Бином Ньютоныч (30.11.03 14:52) [17]

Смысл не совсем познавательный. Возникла трабла с VB 6.0: у мальчика периодически отваливался ексель, с которым он работал через ОЛЕ, отследить это он не мог и при попытке произвести после этого с екселем какое-то действие вся программа вываливалась с ошибкой, которую ON ERROR GOTO не отлавливал, а try except появились только в VB.Net.
Вот я и озадачился вопросом, как в принципе обойтись без try except.

← →
Бином Ньютоныч (2003-12-01 18:39) [20]

>Nikolay M. © (01.12.03 09:36) [19]

Ну VB тут мимо темы потому как работать придется на асме. Если под ХР попробуй использовать векторные обработчики. Смотри AddVectoredExceptionHandler. Тока я те тут не помошник, не пробовал этого зверя.

Может обойтись без VB? :o) В свое время меня падучесть Excel заставила писать генератор xls файлов без участия Excel.

> Бином Ньютоныч (01.12.03 18:39) [20]

Насчет VB не в курсе - а что, там асм-вставок нет? :(
AddVectoredExceptionHandler - знаю, тоже был в мсдн... :?)

> vuk © (01.12.03 19:04) [21]

Знаю, помню, Вы мне даже этот генератор по почте выслали как раз под ту задачу, на которую мы мальчика на VB взяли (года 3 назад) :)
А падучесть VB+Excel - ничто по сравнению с глюкавостью Delphi+Excel, поэтому и брали нового человека. Поскольку нужно было не столько генерить файлы, сколько их читать и разбирать... Но все равно спасибо еще раз :?)

to Nikolay M.:
>Поскольку нужно было не столько генерить файлы, сколько их
>читать и разбирать...
Тогда да, здесь уже никак. Либо через OLE либо опять же строить свой анализатор, что гораздо сложнее генератора. Задачу разбора xls тоже решал. У меня сделан разбор XLS на vb-скриптах, которые используются через Delphi. Но это сделано только из-за того, чтобы не перестраивать программу при изменении внутренней логики разбираемых файлов.

> vuk © (01.12.03 20:19) [23]

Вот-вот. Мы через VB в итоге тоже сделали.
Btw, вы у нас в клиентах ходите ;)
http://www.pricematrix.ru/index.php3?mod=5&letter=Ф&lpos=51

← →
марсианин (2003-12-01 23:09) [25]

2 closer © (01.12.03 05:48) [18]

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

но если его отключить и запустить прогу из-под Делфи нажатием Ф9. то мало того что исключение не обработается, отладчик ввобще его не заметит (окошко, что мол произошло EZeroDivide, не покажется, выполнение кода не остановится на строчке с делением).. что наверное неудивительно, так как EZeroDivide - необьявлен ведь...

Похоже, тут дело не просто в видимости классов исключений, а в самом методе как делфи их обрабатывает.. через создание этих самых классов исключений...а тут СисУтилс жизненно необходим..

неужели по-другому никак?

вообщем ты наверное прав..разве что окошки с ошибками показывать - это дело Делфи (в смысле среды) и Виндоус (мол неустранимая ошибка и тп)..

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