GNOME Bugzilla – Bug 599698
[annotation] return values that are redundant with GError
Last modified: 2015-02-07 16:54:12 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.
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.
(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...)
*** Bug 616376 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of bug 649657 ***
[Mass-moving gobject-introspection tickets to its own Bugzilla product - see bug 708029. Mass-filter your bugmail for this message: introspection20150207 ]