Re: [gtkmm] C & C++ exceptions, FAQ 4.6

[Owen Taylor <otaylor redhat com>]

On Thu, 2003-11-06 at 12:56, gtkmm mailing list account wrote:
> ( Hoping CC to gtk-devel-list is appropriate )
> 
> Le Jeudi 6 Novembre 2003 18:48, Murray Cumming Comneon com a écrit :
> > > Reading the FAQ, I found item 4.6 and it  reminded me I had the
> > > same troubles using at-spi callbacks and C++ exceptions.
> > > It is easly solved on gcc by compiling the C libs with
> > > -fexceptions flag.
> > > Is there any reason for Gtk & Gnome not to be compiled with this
> > > flag by default ?
> > >
> > > I found it really useful to add it in my local .jhbuildrc.
> >
> > You should ask the GTK+ people about that, but I suspect that they
> > will not want to use it simply because it is not the default. It
> > would be difficult to ensure that every rpm and deb of GTK+ was
> > compiled with it.
> 
> I'd expect C ABI to be completely unaffected by this flag, so it 
> wouldn't matter is there is a mix between apps and libs compiled with 
> or without the -fexceptions flag, so you wouldn't have to ensure that 
> every rpm and deb of Gtk+ was compiled with it.
> 
> Of course, unable to garantee that Gtk+ would be compiled with this 
> flag, you (Gtkmm) wouldn't be able to make any promise. It would only 
> be a matter of "quality of implementation" : if your Gtk+ library was 
> compiled with gcc and the -fexceptions flags, your exceptions will be 
> propagated, otherwise, you will be warned at runtime.
> 
> If the Gtk+ configure script sets this flag, I have no doubt packages 
> would follow.
> 
> I don't see any downside in setting this flag when possible, and it 
> might be useful, so why not ?

You can't throw exceptions back through GTK+. As an obvious example,
GTK+ does:

 g_object_ref (object);
 g_signal_emit (object, "clicked");
 g_object_unref (object);

(The ref/unref actually happens inside g_signal_emit().) So throwing
an exception from a signal inevitably leaks memory. There is all
sorts of other internal state you'll corrupt causing subsequent
misbehavior and crashes.

Regards,
						Owen