Re: cannot longjmp from g_log_set_handler function

[Lars Hallberg <lah micropp se>]

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.

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? 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!

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.

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....

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

thanks /Lars