Rob,
Thanks for the reply.
>>> When I caught an exception in methode Execute and re-raise it
>>> in a synchronised TThreadMethode, the RTL tries to free the
>>> Exception-Objekt twice.
>>
>> Ok, finally there is one free-attempt too much. I was confused
>> due to the fact that calling raise E in the synchronized
>> handler did work and the error was thrown later. So I will wrap
>> the call of the exception handler in a try-except block and eat
>> any possible exception there.
>
> No, don't do that. You're just covering up the error. You're not
> solving the problem.
I want to push some jobs into a queue and get their results back
in main thread. 'Fire and Forget', without having to care about
thread creation/termination etc. and with only one place to check
for job-errors. The threads shall be kept running, they must not
be re-created on new jobs.
If there is an unhandled exception in job's execute methode there is
IMHO not much I can do, except that the result event must somehow get
access to the exception object. Were it realy that bad if the writer
of that handler would be responsible to handle *any* exception, since
otherwise it's eaten, I'm not that sure?
Or what about not using standard Synchronize() but for instance
SendMessage(), the an acquired thread exception as well as any new
exception could raise in main thread context, just an idea?
> I told you how to solve it.
Not realy, since AcquireExceptionObject doesn't solve it :) An
exception object has to be freed either by raising it or by .Free.
The pointer to the object however is not niled, so when an acquired
exception is raised from my event handler any subsequent attempt to
free will cause an AV, you cannot know whether it has been freed
previously. Similar happens when the exception is not acquired but
freed/raised in its except block like:
try
raise Exception.Create('Test');
except
on E: Exception do
raise E;
end;
Ok, that's nonsense-code of course.
> I also told you that
> the RTL might already do everything for you, including passing the
> exception to the main thread.
I don't understand what you mean, the execute method terminates
silently when an exception is not handled, the exception is stored
in property FatalException intended to be checked from OnTerminate.
That IMHO just moves the problem (if any) to a different location.
Just for fun, try raising FatalException or raise a newly created,
unhandled exception from OnTerminate and watch the result. The developer
is responsible to handle any exception in OnTerminate, otherwise the
app. may crash and exit.
--
Arno Garrels
_______________________________________________
Delphi mailing list -> [email protected]
http://lists.elists.org/cgi-bin/mailman/listinfo/delphi
