GNOME Bugzilla – Bug 712519
GLib.GError inconsistencies
Last modified: 2014-05-05 07:27:07 UTC
Some minor GLib.GError related issues: ################################################################ >>> GLib.GError <class 'gi._glib.GError'> >>> GLib.GError is GLib.Error False >>> type(GLib.Error.new_literal(1,1,"")) is GLib.GError True Traceback (most recent call last):
+ Trace 232783
doc = P.Document.new_from_file('file:///path/to/a/.pdf', '')
################################################################ * It would be nice it GLib.Error was the same as GLib.GError since only GError can be used to catch exceptions atm. This probably needs implementation of the GLib.Error methods/fields in C to keep it API compatible (??) * It would be nice if the class name of the internal GError class was "GLib.[G]Error" so it would be obvious how to catch the exception based on the traceback. This should be easy I guess.
(In reply to comment #0) > It would be nice it GLib.Error was the same as GLib.GError since only GError > can be used to catch exceptions atm. This probably needs implementation of the > GLib.Error methods/fields in C to keep it API compatible (??) Agreed. The "code" and "domain" fields could just be added to the existing GError class and marshaling should probably fill them out as well: https://git.gnome.org/browse/pygobject/tree/gi/_glib/glibmodule.c?id=3.11.1#n76 We could then just clobber GLib.Error with GLib.GError and monkey patch methods in the GLib overrides.
At the moment methods like g_error_matches are implemented into GLib.Error In [4]: GLib.Error.matches Out[4]: <gi.FunctionInfo object (matches) at 0x0xb5ceb340> and not in GLib.GError In [3]: GLib.GError.matches --------------------------------------------------------------------------- AttributeError Traceback (most recent call last) <ipython-input-3-da6a08a89fa1> in <module>() ----> 1 GLib.GError.matches AttributeError: type object 'GError' has no attribute 'matches' but in some cases such as the signal "parsing-error" of Gtk.CssProvider a GLib.GError is returned gi._glib.GError: <data>:13:13'gree' is not a valid color name <class 'gi._glib.GError'> so it's impossibile to use the above g_error_matches from pygobject
Some initial cleanup to get this started has been committed here: https://git.gnome.org/browse/pygobject/commit/?id=649895d The plan is to add a more complete static binding of GError that will clobber GLib.Error and hold a pointer to a C GError. Since GLib.Error is derived from gi.Boxed, we can never really use this in combination with Pythons builtin Exception class.
The following fix has been pushed: 3083daf Add Python implementation of GError
Created attachment 275864 [details] [review] Add Python implementation of GError Add internally used gi/_error.py module as a basis for implementing a unified GError between introspection and static bindings. Patch Python implementations of GError.matches and GError.new_literal in the GLib overrides
The following fix has been pushed: f80f5ec Simplify pygi_error_marshal to use GError initializer arguments
Created attachment 275866 [details] [review] Simplify pygi_error_marshal to use GError initializer arguments
The following fix has been pushed: 4c2e691 Clobber GLib.Error with custom implementation
Created attachment 275867 [details] [review] Clobber GLib.Error with custom implementation Clobber the introspection GLib.Error class with the custom Python implementation found in gi._error.GError. Update references to GLib.GError to use GLib.Error.