Re: cannot longjmp from g_log_set_handler function

[Owen Taylor <otaylor redhat com>]

Lars Hallberg <lah@micropp.se> writes:

> On Sun, Mar 28, 1999 at 11:56:58PM -0500, Owen Taylor wrote:
> > 
> > (And not just with leaking memory... a lot code in GTK+ assumes 
> > that after you call a callback, it will get control back)
> 
> That means the callback must catch all exeptens themself and
> newer throw any. That is *realy* troublesome and shuld att
> least be clearly documented.

I think people should realize that you simply cannot
throw exceptions through a C library and expect them
to work... (stack frame unwinding will work correctly -
on some compilers - but that is only a small piece
of the puzzle)

I really don't think that we need to document that for GTK+ specifically.
 
> Some internal (probably hairy) API to let objekt oriented
> language bindings to work this out the 'right' way would
> be nice...
> 
> The esiest thing would be to use C++ classes to hold internal
> resorce allocatons and state restoring (but keep the C API).
> Is ther rely anyone needing to compile GTK+ with a C only
> compiler? 

Most likely. Not to mention the fact that we are talking
a noticeable performance hit here by putting a lot
of state on critical code paths into destructors...

(Using actual try {} blocks may do better, because then
the cleanup is only hit on exceptions...)

At this point, making GTK+ use C++ internally is
simply a non-option, I would say.

> It takes no modern C++ compiler to have
> constructors and destructors (and that is all ther needs to
> be used even if templates is konvenient). The old fashion
> C++ -> C konverters shuld realy be able to solv this!

Ummm, 'old-fashioned + C++ == buggy' in my experience ;-)
 
> Exeption ask for a fairly moder C++ compiler but only if they
> are used (and C users will not ;-)
> 
> > Making even a C++ library exception safe is fairly difficult
> > because it is adding a lot of code paths to ones code that
> > are going to be tested only in exceptional situations.
> 
> Is not the hole point with exeptions to reduse the alternative
> code paths?
> 
> if all resorses ar handled by constructor / destructor pair
> (both in norma flow and exeptional flow) the only exeptional
> code path is in the exeption handlers (catch statment). They
> are easy identified and farly testable by delibaratly
> throwing exeptions.
 
There are 228 uses of gtk_signal_emit() in GTK+. 
In any one of these the user could throw an exception...
But not only that, in any function that calls any one
of those functions, you have an extra code path
for exceptions. Not so simple to test out thoroughly...

> Alot of if statment, testing returnvalues from function to
> trap errors givs allot of codepaths that is hidden in the
> 'norma' flow controll and therby hard to test (and makes the
> 'normal' codflow harder to understand and test). To my
> understanding, exeptions is ment to avoid just that....

Well, to put it bluntly, we make that simple in GTK+
by basically not worrying about propagating back error
conditions.

When GTK+ runs into an error, it yells loudly, drops
back to the caller and probably segfaults some time later.

(These are only errors that come about from caller stupidity
or (less commonly) internal logic errors; if there are
expectable error conditions then there will be a 
mechanism to return them)

In general, this produces robust programs if  you simply fix 
all the warnings GTK+ spits out.

> Sorry for sounding so dissaproving and wining. I do realy
> apresiate the GTK+ teams work!

A bit of whining is OK... just as long as this doesn't
turn into the recurring "rewrite the Linux kernel in
C++" thread...
                                        Owen