Trolltech Home | Qt-jambi-interest Home | Recent Threads | All Threads | Author | Date
All threads index page 1

Qt-jambi-interest Archive, November 2006
Exceptions thrown in signal slots

Message 1 in thread

Hello,

I wonder how Jambi handles exceptions that are thrown in the signal 
handler methods? Are they propagated
to any registered Thread.UncaughtExceptionHandler?

Regards,
Helge F.
Message 2 in thread

Helge Fredriksen wrote:
> Hello,
> 
> I wonder how Jambi handles exceptions that are thrown in the signal 
> handler methods? Are they propagated
> to any registered Thread.UncaughtExceptionHandler?

Hi Helge,

Right now, we only print out the stack trace of these exceptions and 
contiune. Propegating these exceptions is definitly a good idea, so 
we'll add support for that.

Keep the good feedback coming ;-)

best regards,
Gunnar
Message 3 in thread

On Thursday 16 November 2006 14:44, Gunnar Sletta wrote:
> Helge Fredriksen wrote:
> > Hello,
> >
> > I wonder how Jambi handles exceptions that are thrown in the signal
> > handler methods? Are they propagated
> > to any registered Thread.UncaughtExceptionHandler?
>
> Hi Helge,
>
> Right now, we only print out the stack trace of these exceptions and
> contiune. Propegating these exceptions is definitly a good idea, so
> we'll add support for that.

I'd say that this should not be done for direct actions (that are not queued) 
as there the InvocationTargetException is a better idea, but having that is 
ugly as sin as it requires all emits to be wrapped in a try{}catch() block.

Basically, all exceptions that happen on the eventQueue (of any thread) should 
be caught (as otherwise the thread will exit) and printed.
And if you don't want to exit it you are not allowed to propagate the 
exception to the Thread.UncaughtExceptionHandler as thats only done by the 
JVM when the thread is actually dying.

So I don't think this is a good idea and basically the concept of emit/connect 
is not suited for exception handling/propagation. There are other design 
patterns for that which allow that (and more) but are a bit more involved to 
setup.

see 
http://developer.classpath.org/doc/java/lang/Thread.UncaughtExceptionHandler.html
-- 
 [ signature omitted ]

Attachment: pgpOl8hnZoLWV.pgp
Description: PGP signature

Message 4 in thread

Thomas Zander wrote:
>>
>>Right now, we only print out the stack trace of these exceptions and
>>contiune. Propegating these exceptions is definitly a good idea, so
>>we'll add support for that.
> 
> 
> I'd say that this should not be done for direct actions (that are not queued) 
> as there the InvocationTargetException is a better idea, but having that is 
> ugly as sin as it requires all emits to be wrapped in a try{}catch() block.
> 
> Basically, all exceptions that happen on the eventQueue (of any thread) should 
> be caught (as otherwise the thread will exit) and printed.
> And if you don't want to exit it you are not allowed to propagate the 
> exception to the Thread.UncaughtExceptionHandler as thats only done by the 
> JVM when the thread is actually dying.
> 
> So I don't think this is a good idea and basically the concept of emit/connect 
> is not suited for exception handling/propagation. There are other design 
> patterns for that which allow that (and more) but are a bit more involved to 
> setup.

Hi Thomas,

Thanks for point out these details.

Exceptions may happen in the user code if its designed to or not, so 
ignoring them is not really ideal ;-) Right now we just print the 
errors, so giving the user access to the fact that an exception happened 
, rather than just printing it out quietly. On windows with javaw that 
won't even be visible...

I'm not saying that we'll use the UncaughtExceptionHandler API, but the 
option of taking action when a user event spun off an exception is in 
general a good thing, and thats what we'll add support for.

-
Gunnar
Message 5 in thread

On Thursday 16 November 2006 15:58, Gunnar Sletta wrote:
> I'm not saying that we'll use the UncaughtExceptionHandler API, but the
> option of taking action when a user event spun off an exception is in
> general a good thing, and thats what we'll add support for.

I fully agree with that, I love using exceptions :)

Using eventQueues changes the context severely, though.
It just like showing a dialog non-modal, you can't expect the original thread 
to do anything with the results, the application programmer has to do all its 
error handling in the dialog-class due to the a-synchronous design.

So, just like that dialog should handle all errors on its own, so should an 
event-handler. And thus should the call to 'emit' itself not know about 
possible exceptions.

Or, look at it from another side; Exception handling is just another 
flow-control mechanism. Just like 'break' or 'return' throwing an exception 
changes the program flow. The original poster seems to want to use it for 
error reporting, which is not the same thing.

I'm naturally not sure what Qts design there will turn out to be, but I have 
seem quite some frameworks struggle with this question and they tend to mix 
up error-reporting and flow control. Two distinct parts of Exception 
programming.

Having a connection to QTextEdit::setText() and a
 emit textChanged(0);
will probably end up with a NullPointerException.
And I fear that having the emit throw that exception only if the textEdit is 
of the same thread is going to be highly confusing for users.

So, my position is that exception handling should be done in the 
signal-handling code and not outside.


ps. your point of javaw showing output that the user doesn't see just means 
you need to use a logging framework.
-- 
 [ signature omitted ]

Attachment: pgpySKZLlV4jO.pgp
Description: PGP signature