With "worth it" I mean the following situations:
DosKillProcess
won't be
able to terminate that thread. You'd have to reboot to get out of this.
So the exception handler must always check for whether a mutex semaphore
is currently owned by the thread and, if so, release it.
DosSetExceptionHandler()
).
The code for exception handlers has been made independent of XWorkplace
and moved to /helpers/except.c
with V0.9.0.
Also, I have created a few handy macros which automatically register and
deregister the XWorkplace exception handlers. This avoids the frequent problem
that one forgets to deregister an exception handler, which leads to
really awkward problems which are almost impossible to debug.
Those macros are called TRY_xxx
and CATCH
to
mimic at least some C++ syntax.
See the top of src\helpers\except.c
for detailed instructions how
to use these.
The XWorkplace exception handlers are the following:
excHandlerLoud
is the one that makes the loud sounds
and writes the XFLDTRAP.LOG
file which is well-known to many XWorkplace users (grin). It uses
a longjmp()
to get back to the function, which might then
react to that exception by trying to restore some safe
state of the thread. See the func header for details about
how this works.
This handler is used by all the additional XWorkplace threads and also by the subclassed folder frame and folder content menu window procs. This slows down the system a bit because the handler must be registered and deregistered for each message that comes in, but there's no other way to do this. (I think.)
With V0.84, I have added lots of debugging code which I found in
the EXCEPTQ.ZIP package at Hobbes. The exception handlers are now capable
of finding symbols either from debug code (if present) or from a SYM file
in order to write more meaningful trap logs.
See the top of except.c
for details.
excHandlerQuiet
is similar to excHandlerPlus
in that it
uses a longjmp()
also, but neither is this reported to the
user nor is the logfile written to (that's why it's "quiet").
This is used in places where exceptions have ben known
to occur and there's no way to get around them. I created
this handler for V0.80 because I found out that somIsObj()
is not a fail-safe routine to find out if a SOM pointer
is valid, even though IBM claims it is.
(These were the strange errors in the Worker thread which appeared in V0.71 when folders with subfolders were deleted, because the Worker thread then tried to access these objects when the folder was populated right before deletion.)
So I created the wpshCheckObject
func which can
return FALSE, using this handler, if access to the object
fails.