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.
_______________________________________________
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
