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 602449 - errors from introspected functions should throw the GLib.Error
errors from introspected functions should throw the GLib.Error
Status: RESOLVED DUPLICATE of bug 591480
Product: gjs
Classification: Bindings
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gjs-maint
gjs-maint
Depends on:
Blocks:
 
 
Reported: 2009-11-19 21:02 UTC by Dan Winship
Modified: 2009-11-19 21:05 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Dan Winship 2009-11-19 21:02:22 UTC
Many methods return GErrors with domain and code set to useful things that the caller can interpret. But gjs throws that info away. (Even when the code isn't useful, the original GError's message may at least be user-presentable, while the gjs-ified version with "Error invoking Blah.blah" prepended to it really isn't.)

So, when an introspected method returns a GError, gjs should just wrap it and throw the GLib.Error rather than creating a generic js Error. (Javascript allows throwing any object, not just subclasses of Error. And most code doesn't look at anything besides the error's 'message' property, and GLib.Error has one of those too, so callers shouldn't even notice the switcheroo. If we wanted to be paranoid we could throw a plain Error with a "gerror" property added to it or something though I guess.)

If this makes sense I can write a patch.
Comment 1 Colin Walters 2009-11-19 21:04:41 UTC
Throwing a GLib.Error with a message (and code) property seems sane to me.
Comment 2 Owen Taylor 2009-11-19 21:05:27 UTC

*** This bug has been marked as a duplicate of bug 591480 ***