Re: [Java-gnome-developer] GTK Warnings

[Andrew C. <an...@op...>]

Hi Niranjan,

On Thu, 2013-01-10 at 13:30 -0800, Niranjan Rao wrote:
> Seems like java-gnome treats like GTK warnings as fatal errors. 

That's true.

The reason is that a Gtk-WARNING is an indication that an illegal
argument was passed to a function. How is the program supposed to
continue if that has been done?

More to the point, in Java we debug uncaught exceptions aka programming
errors by seeing a stack trace that takes us right through the code path
that led from the developer's mistake to the code which checked for the
condition.

We do our best to have guards in the bindings layer, but there are a
fair number of conditions which arise because of mistakes that don't
become apparent until runtime due to the very dynamic nature of GTK.

Anyway, yes: to make java-gnome fit in to Java programming better,
WARNINGs are converted to unchecked exceptions.
 

> Is there 
> any flag that I can use to say log the warning, but don't treat it as 
> fatal error.

No there isn't. We can have a conversation on java-gnome-hackers if you
want to talk about engineering a different solution to this, but you'd
have to answer the question of how what you want to do is better than
the programmer getting an unchecked exception that they have to deal
with so as to correct their code.

> I have integrated webkit and in general it works fine and I get most of 
> the functionality of web kit I care to have. Depending upon what we are 
> doing, sometime we have to enable WBKIT_DEBUG flag and use it with 
> webkit debug version. If we switch webkit to standard library and forget 
> to remove the WEBKIT_DEBUG flag, webkit just logs a warning about log 
> not being available. This causes java gnome to crash.

Sounds like it is doing the right thing? If you the programmer have
forgotten to do something, shouldn't the program terminate?

> We would prefer to 
> see those warning so that we know what's happening.
> Normally you will get the warnings on stdout/stderr, but our code runs 
> with daemon/xvfb combo

Shouldn't the output end up in ~/.xsession-errors, then?

AfC
Sydney