Ошибка в деструкторе TThread?

← →
Erik1 (2004-08-31 15:14) [0]

Если происходит исключение внутри конструктора TThread, то при вызове TThread.WaitFor в нем происходит ошибка "EExternalException in module ntdll.dll at 0001FFE4 External exception C0000008". Что тут можно сделать? Причем вылетает это на вызове "while MsgWaitForMultipleObjects(1, H, False, INFINITE,
QS_SENDMESSAGE) = WAIT_OBJECT_0 + 1 do PeekMessage(Msg, 0, 0, 0, PM_NOREMOVE)"

← →
TUser © (2004-08-31 15:17) [1]

Во-первых где происходит ошибка - в конструкторе или в деструкторе. Если последнее - то зачем ты вызываешь WaitFor?

← →
KSergey © (2004-08-31 15:18) [2]

Что-то я не понял: в кострукторе исключение, т.е. объект не создался. О вызове каких других методов данного экземпляра (которого и нет вовсе!) можно говорить-то?

← →
Erik1 (2004-08-31 15:22) [3]

Вы забыли, что если в конструкторе происходит исключение то автоматически вызывается деструктор. А вот в деструкторе TThread и начинабтся проблемы. По моему ясно что TThread это не мой класс и если там вызывается WaitFor значит это нужно.

← →
VMcL © (2004-08-31 15:24) [4]

>>KSergey © (31.08.04 15:18) [2]

>Что-то я не понял: в кострукторе исключение, т.е. объект не создался.

Создался. Просто не(до)инициализорован.

← →
KSergey © (2004-08-31 15:28) [5]

> [4] VMcL © (31.08.04 15:24)
> >Что-то я не понял: в кострукторе исключение, т.е. объект
> не создался.
>
> Создался. Просто не(до)инициализорован.

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

Однако c точки зрения кода за пределами конструктора - экземпляр именно не создасться!

Однако, автор про стандартный деструктор TThread что-то гутарит.. Не силен я, конечно, но сомнения меня как-то разбирают в части наличия там проблем.. Хотя - как знать, конечно

← →
Суслик © (2004-08-31 15:37) [6]

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

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

← →
KSergey © (2004-08-31 15:39) [7]

> [5] KSergey © (31.08.04 15:28)
> недоинициилизированными данными просто не будут выполняться

С учетом поправки

> [6] Суслик © (31.08.04 15:37)

уточню, что имелось в виду конечно

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

Ясно, что в деструкторе это надо учесть

← →
Erik1 (2004-08-31 15:47) [8]

Разумеется я все учел, мой деструктор выполняется без сучка и задоренки. А вот когда я делаю inherited и вызывается родной деструктор TThread, тогда и начинаются проблемы. Я же писал, что это немая ошибка. Пока перодолел проблему так:
В конструкторе опустил inherited Create ниже.
Var UDPServer: TIdUDPServer;
begin
UDPServer := TIdUDPServer.Create(nil);
with IdUDPServer do begin
................
Active := True;
end;
inherited Create(LogFile, 5000);
IdUDPServer := UDPServer; //присваеваем полю класса
Но всеравно обидно.

← →
KSergey © (2004-08-31 16:08) [9]

> [8] Erik1 (31.08.04 15:47)
> inherited Create(LogFile, 5000);

И вы будете утверждать, что это вызов конструктора TThread???
К стати, есть еще такой момент. Надо не забывать, что при вызове конструктора TThread с параметром False сразу создает объект виндовс "поток", код котрого начинает выполняться! (т.е. код из Execute)
И если там используются какие-то данные, инициализируемые в конструкторе, но ниже inherited - то сами понимаете...

> В конструкторе опустил inherited Create ниже.

Законно

← →
Erik1 (2004-08-31 16:45) [10]

Ну у меня дилнное наследование, если нитересно то
TRealEvent = class(TLogThread)
TLogThread = class(TCustomThread)
TCustomThread = class(TThread)
В конечном итоге вызывается Constructor TThread.
У меня в кострукторе TCustomThread вконце стоял resume, попробовал убрать и возвратить старый код. Вроде получше стало, но доконца непомогло. Оставил вариант с вызовом inherited Create в конце конструктора.

← →
KSergey © (2004-08-31 18:57) [11]

> Erik1 (31.08.04 16:45) [10]
> Ну у меня дилнное наследование, если нитересно то

Все же еще раз спрошу: вы до сих пор уверены, что

> Erik1 (31.08.04 15:47) [8]
> А вот когда я делаю inherited и вызывается
> родной деструктор TThread, тогда и начинаются проблемы.

??
Вот я все же сиильно сомневаюсь.

← →
Erik1 (2004-09-01 10:10) [12]

Полностью уверен, у меня создается и уничтожатся пара event еще чегото по мелочи. Я даже скомпилил с Debug DCU и проверил в отладчике. В принципе надобы в подводные камни отправить на королевство.

Тогда можно сюда минимальный код, на котором это проявляется? Мне тоже любопытно.

А если сделать class procedure Create, которая вызывает конструктор, не создавая исключений, а просто возвращая nil?

> KSergey © (31.08.04 16:08) [9]
>И если там используются какие-то данные, инициализируемые в >конструкторе, но ниже inherited - то сами понимаете...

типа, не прав ты...

создается то сразу, но запускается только после отработки конструктора в aftercontruction

как минимум так в шестерке...

← →
Erik1 (2004-09-02 14:34) [16]

Был дополнительный exception в нижележащем деструкторе, в результате управление передавалась верхнему деструктору, но там стояли проверки на nil и все отрабатывало нормально. А когда дело доходило до деструктора TThread то возникала ошибка на WinAPI. Вобщем код поправил и все заработало полностью коректно.

Ошибка в деструкторе TThread? Найти похожие ветки