Re: Musings on the proper use of g_error and GError

[Edward Catmur <ed catmur co uk>]

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.