Re: Musings on the proper use of g_error and GError

Suppose one issues a connect() on a socket fd. Would it be correct to set a GError if the call returned a "soft" error code like EAGAIN or ECONNREFUSED, but to throw a hard g_error if it were, e.g. EFAULT? "Recoverable" is in the eye of the beholder, no? Also, since "g_error should only be used

Re: Musings on the proper use of g_error and GError

On 9/2/06, Edward Catmur <[EMAIL PROTECTED]> 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 alloc

Re: Musings on the proper use of g_error and GError

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

Musings on the proper use of g_error and GError

The glib documentation on error reporting is very specific on differentiating between runtime recoverable errors and programming errors: http://developer.gnome.org/doc/API/2.0/glib/glib-Error-Reporting.html Of interest to me is the rather strong statement that: "... the |g_error()|