Re: GNOME GTK-- Projects

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

Chen, Alan wrote:
> 
> John R. Sheets wrote:
> 
>         >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.
> 
> If GTK+ had a callback for error handling, a GTK-- program
> could register a callback that checks the error type and
> throws the right GTK-- exception and a GTK+ based program
> would register its own error handling code.  The GTK+
> behavior could also be the default for GTK-- compiled w/o
> aedquate compiler support for exceptions... Does that
> sound feasible?

Yes, it does.  But do you think that would solve the problem with
passing exceptions through C-code?  

As I see it (correct me when I'm wrong), the problem lies in
exactly when the exception is thrown.  1) Do we throw it when the
error occurs, thus leading to an exception being thrown while
we're still processing C-code?  or 2) Do we set a flag when the
error occurs, and rely on error-polling when we finally return to
C++ code?

John