GNOME Bugzilla – Bug 726775
clarify expectations with generic errors like G_IO_ERROR_FAILED
Last modified: 2014-06-28 17:44:53 UTC
See patch. This attempts to clarify that GIOErrorEnum may be extended in the future, and that this may cause some situations that currently return G_IO_ERROR_FAILED to return a different error code. (In particular, the thing that started this was that I want to make EAFNOSUPPORT ("no support for address family") return G_IO_ERROR_NOT_SUPPORTED rather than the current value of G_IO_ERROR_FAILED.) Note that we have done this at least once before, as seen by this code in glib-networking: if (g_error_matches (my_error, G_IO_ERROR, G_IO_ERROR_FAILED) || #if GLIB_CHECK_VERSION (2, 35, 3) g_error_matches (my_error, G_IO_ERROR, G_IO_ERROR_BROKEN_PIPE) || #endif ... Besides the glib-networking example above, a grep of 'g_error_matches.*ERROR_FAILED\W' in a (not-entirely-up-to-date) checkout of jhbuild shows only two other hits: NetworkManager comparing against G_FILE_ERROR_FAILED, but only to decide between log levels: if (!g_file_get_contents (path, &contents, NULL, &error)) { /* We assume FAILED means EOPNOTSUP */ if ( g_error_matches (error, G_FILE_ERROR, G_FILE_ERROR_NOENT) || g_error_matches (error, G_FILE_ERROR, G_FILE_ERROR_FAILED)) debug ("error reading %s: %s", path, error->message); else error ("error reading %s: %s", path, error->message); (and GFileError seems unlikely to ever include an error for EOPNOTSUP anyway; this code is reading from sysfs). gcr comparing against G_SPAWN_ERROR_FAILED in a way that probably makes sense: if (g_error_matches (error, G_SPAWN_ERROR, G_SPAWN_ERROR_FAILED) && self->pv->first_error) { g_simple_async_result_set_error (res, G_SPAWN_ERROR, G_SPAWN_ERROR_FAILED, "%s", self->pv->first_error); g_error_free (error); } else { g_simple_async_result_take_error (res, error); }
Created attachment 272483 [details] [review] Clarify expectations with error codes like G_IO_ERROR_FAILED If an error code enumeration is expected to be extended in the future, people shouldn't compare explicitly against its generic "FAILED" value.
Review of attachment 272483 [details] [review]: ::: glib/gerror.c @@ +512,3 @@ + * equilalent to the `FAILED` code. This way, if the domain is + * extended in the future to provide a more specific error code for + * a certain case, your code will still work. Looks good.
pushed to master and glib-2-40