In Bug #45845 "Falcon crashes while running falcon_bug_36294-big test"
(http://bugs.mysql.com/bug.php?id=45845) Ann brings up the issue of that
we in Thread::thread() catches an exception and the rethrows it
immediately without any other code catching it leading to a process
crash. I agree that this is a problem.
I have twice run into this code and been tempted to do something about
it but not known what was best way to deal with it. I see at least two
issues with the code as it is now:
1. The main issue is that we have an Falcon internal thread that has
thrown an exception that is likely due to something "very serious" since
it is not handled anywhere (or it caused by a coding bug) . So at this
point in the code we are basically handling an exception that the
thread's own code did not manage to handle. Unfortunately, as the code
is now it leads to a process crash. What is the alternative? It is
fairly easy to avoid the process crash by just catching the exception -
but what should we do with the thread (or rather the lack of this
thread)? Should we just restart the same thread? Continue without this
thread? In many cases the cause for the exception is so serious that
Falcon will not be able to continue.
The best we can do is probably to try to restart the crashed thread
- and hope the issue was temporarily? The second best is probably to let
the thread die and just continue as if nothing had happened...
2. Another issue is that if we continue to let this lead to process
crashes - the catch/rethrow is mostly annoying (at least for developers)
since it leads to a call stack that just shows where the rethrow took
place and not where the initial problem was. This makes it much harder
to identify what was the real cause for the crash. I did a commit last
week where I changed the logging code so that we at least write to the
log what kind of exception this was - earlier this catch/rethrow was
done "silently" (if there was not debug flags specified).