From: Olav Sandstaa
Date: July 2 2009 2:02pm
Subject: Catch and rethrow of exceptions in Thread::thread()
List-Archive: http://lists.mysql.com/falcon/777
Message-Id: <4A4CBDEB.3000405@sun.com>
MIME-Version: 1.0
Content-Type: text/plain; CHARSET=US-ASCII; format=flowed
Content-Transfer-Encoding: 7BIT

Hi,

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).

Olav