On Thu, 16 May 2019, Sven Barth via fpc-pascal wrote:
Karoly Balogh (Charlie/SGR) <char...@scenergy.dfmk.hu> schrieb am Mi., 15.
Mai 2019, 18:40:
Hi,
On Wed, 15 May 2019, Sven Barth via fpc-pascal wrote:
(Sidenote: I've been pondering for a while if I should report this as a
bug. I think the RTL should put a try-except around there, to show a
stacktrace on unhandled exceptions, just like the main thread dying
does, but who knows which Delphi de-facto standard behavior would that
violate, so meh...)
That is already the case at least for TThread descendants as can be seen
in rtl/unix/tthread.inc, ThreadFunc. This is needed for the
FatalException field.
Hmm, I see, indeed. Should have checked the source code, but I never
cared... -.-' Well, the stacktrace is stilly only printed on DEBUG_MT, if
i'm correct?, so from the developer's perspective, the thread is still
dying 'silently', and sometimes it's hard to identify if your thread went
away or just blocked, when seeing an issue... Anyway, not important and
unrelated here.
It won't terminate quietly, because FatalException will be set in that case
(of course assuming that FreeOnTerminate is false). This means that the
user must actively check whether a thread crashed. But that would be the
necessary with any other mechanism as well, cause we don't want to
automatically print a stack trace as the developer might not want that or
it might not even be possible (e.g. writing to StdOut or StdErr would not
be possible on Windows for GUI applications).
Though maybe one could add an event that is triggered when an exception had
been raised. That would give the developer the opportunity to handle the
exception when it occurred.
Seeing that the FatalException property exists, an event
Property OnFatalException : TNotifyEvent;
seems indeed appropriate.
Michael.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
