In my case, the need for all this exception machinery came from the fact that QT3 does not allow to use a QProcess in a thread because QThread does not have an event loop.

My core part functions are similar to this one:

foo()
result1 = run() ;// call external program executer

input2 = g(result1);

result2 = run(input2);

input3 = h(result2);

result3 = run(input3);

return result3;

where run() launches a process and waits on

while(busy)
qApp->processEvents();

'busy' is reset in processExit(). I want a simple semantics for run() function, without callbacks and splitted launch/exit with async execution, this is the reason of the while loop, and, in any case , also with callbacks on processExit() the problem is not changed, I need to test the context when returning from processExit().

You suggest to avoid exceptions in GUI part. But exceptions, at least in my case, came _all_ from GUI part: resetting, closing windows, refreshing, opening a directory/archive while core is updating another, changing row selection while core is still processing the current one, and so on, the list is long.

I have tried to filter out events with QEventLoop::ExcludeUserInput during updating, but the results are sub-optimal, missing drag&drop or drag started but not ended(missing mouse relase button event) and so on.

The problem is that QEventLoop::ExcludeUserInput does not queue events to be processed later, but filter them outs forever.

I have googled around before to re-invent the wheel, but I wasn't able to find anything.

Thanks for yous feedback.
I am very interested to hear from you what do you think about this.

Marco