[fpc-pascal] unexpected termination with no errors

Michael Van Canneyt michael at freepascal.org
Thu May 16 11:45:11 CEST 2019



On Thu, 16 May 2019, Sven Barth via fpc-pascal wrote:

> Karoly Balogh (Charlie/SGR) <charlie at 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.



More information about the fpc-pascal mailing list