Re: Musings on the proper use of g_error and GError

["Samuel Cormier-Iijima" <sciyoshi gmail com>]

On 9/2/06, Edward Catmur <ed catmur co uk> wrote:
> On Sat, 2006-09-02 at 13:19 -0400, Philip Kovacs wrote:
> > Looking at the glib code itself, e.g. in gmem.c:  in the g_malloc()
> > function,
> >  if the memory was not allocated as expected, glib does this:
> >
> > g_error ("%s: failed to allocate %lu bytes", G_STRLOC, n_bytes);
> >
> > Clearly this is not a "programming" error, it is a runtime error, so it
> > leaves
> > me questioning the clarity of documentation.  Does the statement mean
> > that if you are using GError in the api and you get a runtime error, you
> > should favor setting a GError over using g_error, BUT, if you are not
> > using GError in the api, then it is ok to issue a g_error?
>
> Failure to allocate memory is not recoverable¹. GError is
> for /recoverable/ runtime error conditions.
>
> > "These two kinds of errors are fundamentally different: runtime errors
> > should be handled
> > or reported to the user, programming errors should be eliminated by
> > fixing the bug in the
> > program.
> > "This is why most functions in GLib and GTK+ do not use the GError
> > <http://developer.gnome.org/doc/API/2.0/glib/glib-Error-Reporting.html#GError>
> > facility."
> > That conclusion does not seem to follow naturally from the precending
> > statement.
>
> GLib does not encounter recoverable runtime error conditions. GTK+ does
> not, really; error conditions on the GDK/window system boundary are
> handled in different ways. GdkPixbuf /does/ use GError, because it can
> hit file errors and format errors.
>
> Ed
>
> [1] OK, if you're writing an air traffic control app, you need to be
> able to recover from malloc failure. Air traffic control apps shouldn't
> use GLib.

On that note, is it possible (with environment variables or #defines)
to make GLib recover from such failures?