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 599698 - [annotation] return values that are redundant with GError
[annotation] return values that are redundant with GError
Status: RESOLVED DUPLICATE of bug 649657
Product: gobject-introspection
Classification: Platform
Component: general
2.21.x
Other Linux
: Normal enhancement
: ---
Assigned To: gobject-introspection Maintainer(s)
gobject-introspection Maintainer(s)
: 616376 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2009-10-26 21:13 UTC by Dan Winship
Modified: 2015-02-07 16:54 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Dan Winship 2009-10-26 21:13:13 UTC
lots of methods return a gboolean that is redundant with their GError parameter; the return value is FALSE if the error is set, and TRUE if the error is clear.

In bindings that turn GErrors into exceptions, these return values are pointless, but mostly harmless, because you can just pretend the function is void. (Though some languages might warn about you ignoring the return value?)

However, in bindings that also turn out args into extra return values, the "real" return value becomes annoying. Eg:

gboolean g_shell_parse_argv (const gchar   *command_line,
                             gint          *argcp,
                             gchar       ***argvp,
                             GError       **error);

in gjs, you would call this by doing something like:

    try {
        let [success, argc, argv] = GLib.shell_parse_argv(command_line);
        ...;
    } catch (e) {
        ...;
    }

But the "success" variable is completely useless, because it will always be true.

So it would be nice if you could say:

 * Return value: (no-error): %TRUE on success, %FALSE if error set

and then the binding would know that the return value was redundant with the GError, and could strip it out. Presumably this would only be allowed when the return value type was gboolean.
Comment 1 Colin Walters 2009-11-02 16:51:15 UTC
Hmm...seems like something a binding could just do by default for booleans, no?  With the caveat that if your binding is already deployed it would break API.
Comment 2 Dan Winship 2009-11-02 17:43:14 UTC
(In reply to comment #1)
> Hmm...seems like something a binding could just do by default for booleans, no?

Yeah, actually the GError docs say:

    * By convention, if you return a boolean value indicating success then TRUE means success and FALSE means failure. If FALSE is returned, the error must be set to a non-NULL value.

so anyone doing otherwise probably deserves to lose

>  With the caveat that if your binding is already deployed it would break API.

yeah, but we're not at "gobject-introspection 1.0" yet, right?

(If the introspection data included a table giving the dates of various releases, then the binding could look at "since" tags on methods, and only use the new rules for methods added after a certain date...)
Comment 3 Dan Winship 2010-04-21 13:38:12 UTC
*** Bug 616376 has been marked as a duplicate of this bug. ***
Comment 4 Dan Winship 2011-05-15 13:58:22 UTC

*** This bug has been marked as a duplicate of bug 649657 ***
Comment 5 André Klapper 2015-02-07 16:54:12 UTC
[Mass-moving gobject-introspection tickets to its own Bugzilla product - see bug 708029. Mass-filter your bugmail for this message: introspection20150207 ]