Re: GNOME GTK-- Projects

[John R Sheets <dusk smsi-roman com>]

Michael Hudson wrote:
> 
> On Mon, 1 Jun 1998, John R Sheets wrote:
> > Michael Hudson wrote:
> > Got any ideas for an alternative?  Perhaps a C++ extension to
> > whichever GTK+ configurable error reporting scheme (yet to be
> > implemented), that doesn't use real exception handling (i.e. a
> > hack)?  Is there any hope for being able to use exception
> > handling in GTK--?
> 
> So long as you delay the thrown excpetion until you're back in GTK-- land
> you should be safe, but that's going to be hard, I should think.
> Perhaps an error handler that set some appropriate static flag variable,
> then when gtk returns normally, gtk-- would translate that into an
> exception. Don't know if that would be feasible. (Don't mention threads).

That's kind of what I was thinking...if the GTK+ function chokes,
it sets a flag or calls some error signal callback, then dies. 
The C++ wrapper acknowledges the error and throws an exception or
pursues some alternate tactic (e.g. I dunno...maybe it changes a
property and tries the same operation again.). 

The problem with this is that every time you access a GTK+
function, you have to check the error flag.  This kinda runs
counter to the intent of exceptions being more passive, more
event-driven.  The longjmp may be a performance hit, but even
more so will be this constant error polling.

Kind of a sticky situation.  No easy answers.

John