[Interest] Logging meta call events

[alexander golks]

Am Tue, 17 Feb 2015 23:23:44 -0800
schrieb Thiago Macieira <thiago.macieira at intel.com>:

> On Wednesday 18 February 2015 07:59:09 alexander golks wrote:
> > if you really want to log, why not just include the private header and do
> > the logging? we do it in our derived q(core)application::notify, when
> > catching exceptions during notify:
> > 
> > #include <../../src/qtbase/src/corelib/kernel/qobject_p.h>
> > 
> >   //...
> >   QMetaCallEvent* metaCallEvent=dynamic_cast<QMetaCallEvent*>(event);
> >   if(metaCallEvent)
> >   {
> >     eventInfo+="\nmetacall event";
> >     eventInfo+="\nevent id: "+QString::number(metaCallEvent->id());
> >     eventInfo+="\nevent sender: "+getObjectInfo(metaCallEvent->sender());
> >     eventInfo+="\nevent: "+QString::number(metaCallEvent->signalId());
> >   }
> 
> Meta call events only happen for queued slot deliveries. For direct 
> deliveries, there's no event, so notify() will not be called. For those, you 
> need to use the hooks that QSignalSpy uses.
> 
> One more thing: catching exceptions during notify() is too late. The exception 
> may have caused a lot of damage inside Qt before it reached notify(). If you 
> need to recover, you need to catch it earlier. If the exception reaches 
> notify(), you should interrupt the event loop and exit the application -- for 
> example, by rethrowing.
> 

thanks for explanations.
we are using this to get a kind of "backtrace" and beeing able to at least try
to identify why our app crashs, as we are using many 3party libraries and plugins,
which don't care if they throw inside a slot/event.

but my point is, when he wants to use the private header, why not?

-- 
/*
 *"It is a beta, but is fairly stable. As with any beta things can go wrong."
 *
 *Husse Jul 25 2007
 */
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20150218/6f8acf03/attachment.sig>