[Development] Allowing event delivery prior to and after QCoreApplication

[Thiago Macieira]

On Wednesday 15 April 2015 20:49:42 Julien Cugnière wrote:
> The idea is that we have threads which serve requests from other
> threads through the use of slots. When an exception is thrown during
> the processing of such a slot, it means the request encountered a
> fatal error and was aborted. But the thread should continue executing
> and serving other requests.
> 
> Same thing with a thread executing a periodic task through the use a
> QTimer. A particular execution of the task could fail through an
> exception, but the task can be retried the next time the timer fires.

I understand what you're saying. My point is that handling error conditions 
from the functions you call is not part of events and the slot activator's job 
descriptions. It's your job.

And since we do not guarantee that you won't crash before reaching notify() or 
leak resources, you're in unsupported land. I am willing to make it supported, 
but differently.

> > The code above will continue to work for the main thread, but will stop
> > working for auxiliary threads. And there will be no work around. You will
> > need to do the right thing and stop any exceptions from going back to the
> > signal- slot mechanism and the event delivery mechanism.
> 
> But this requires wrapping every single slot in a try/catch. Apart
> from the code churn (we have lots of those), this is repetitive and
> error-prone, as it's all too easy to add a new slot and forget the
> try/catch. The software is much more robust and maintainable if the
> catching of exceptions can be centralized.

I think we'll have to agree to disagree.

One of the reasons I don't like exceptions is that I philosophically think 
that you should never have catch-alls. It means someone did not do their job 
right. My reasoning is that catch-alls indicate all the error details have 
been lost and the handler can only wield the big hammer as a solution (abort 
completely or continue despite the errors).

> Our use of QCoreApplication::notify is intended to solve the problem I
> describe above by moving the try/catch one level up in the call stack
> 
> : instead of doing it in the slot itself, we want it done in the
> 
> caller of the slot.
> 
> If notify is too far up the stack, it would be fine doing it closer to
> the user code. I suppose for slots you're thinking of
> qt_static_metacall or QMetaObject::activate.

Yes, QMetaObject::activate is the one I'm thinking of.

> But ideally it would need to go through a user-supplied function, to
> be able to customize the type of exception caught, and the way they
> are handled (logged in our case). Wouldn't that bring the same kind of
> problem as QCoreApplication::notify ?

My idea is to provide you with the ability to:
 - decide whether to catch or not
 - supply a handler that will be called if an exception is caught
 - decide whether a caught exception resumes execution or aborts the 
   application (after your handler)

If you need access to the exception itself, you can use the C++ runtime to get 
it.

> Or if it can't go through a user supplied function, at the very least
> Qt should catch std::exception, and log its message through a
> user-customizable function (such as qWarning()). A simple catch(...)
> wouldn't be enough, as the text of the exception would be lost.

See above. The runtime allows you to get it. But we could handle 
std::exception specially, indeed.

> By the way, thanks for taking the time of discussing this use-case.

No problem, input is welcome.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center