After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 689452 - G_SPAWN_EXIT_ERROR not (nicely) introspectable
G_SPAWN_EXIT_ERROR not (nicely) introspectable
Status: RESOLVED WONTFIX
Product: gobject-introspection
Classification: Platform
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gobject-introspection Maintainer(s)
gobject-introspection Maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2012-12-01 19:32 UTC by Colin Walters
Modified: 2018-01-24 19:25 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Colin Walters 2012-12-01 19:32:13 UTC 
g_spawn_check_exit_status() and its error domain G_SPAWN_EXIT_ERROR were introduced in:

https://bugzilla.gnome.org/show_bug.cgi?id=679691

First, an ugly aspect of this is that the function can throw two separate domains that you have to handle.

The next problem is G_SPAWN_EXIT_ERROR has no corresponding enumeration for error codes, which means introspection won't have nice GError handling for it.  This is what you have to do in gjs at the moment if you want to catch a spawn error and just extract the message:

	try {
	    GLib.spawn_check_exit_status(estatus);
	    success = true;
	} catch (e) {
            if (e.matches(GLib.SpawnError, GLib.SpawnError.Failed ||
                e.domain == GLib.spawn_exit_error_quark())
              errorMsg = e.message();
            else
               throw e;
	}

The way we stuff the exit code into the error code means that if we wanted to have a corresponding enumeration, it'd need to have 255 members =/  Kind of ugly...
Comment 1 Dan Winship 2012-12-01 20:52:35 UTC 
(In reply to comment #0)
> First, an ugly aspect of this is that the function can throw two separate
> domains that you have to handle.

I don't consider that ugly. You wouldn't really need error domains if every function only returned errors from a single domain. It's true that not many functions in glib currently return errors from multiple domains, but that's just because not many functions in glib are complicated enough that they can fail in multiple categories of ways. But, eg, g_tls_connection_handshake() can can fail due to either I/O problems or due to certificate-related problems, so it can throw either G_IO_ERROR or G_TLS_ERROR.

>             if (e.matches(GLib.SpawnError, GLib.SpawnError.Failed) ||
>                 e.domain == GLib.spawn_exit_error_quark())

That's ugly though...

Making the second argument to GLib.Error.matches() be optional would be one fix...
Comment 2 André Klapper 2015-02-07 17:17:59 UTC 
[Mass-moving gobject-introspection tickets to its own Bugzilla product - see bug 708029. Mass-filter your bugmail for this message: introspection20150207 ]
Comment 3 Emmanuele Bassi (:ebassi) 2018-01-24 19:25:59 UTC 
I don't think there's anything to fix in g-i. Fixing the ugliness of g_spawn_exit_error_quark() should be opened as a bug in GLib.