GNOME Bugzilla – Bug 684969
Use g_dataset_id_set_data() to store remote errors in GError
Last modified: 2018-05-24 14:40:44 UTC
Currently GDBus prepends remote DBus error strings in the @message parameter of GError. This changed the semantics of the @message parameter from a human-readable string to a sorta structured string. It requires constant use of g_dbus_error_strip_remote_error() in code, which everybody forgets to do. We can just use g_dataset_id_set_data_full() with a unique quark and a pointer to the GError struct to store a the remote error string. g_error_free() would need to call g_dataset_destroy() with a pointer to itself. g_dbus_error_get_remote_error() would use g_dataset_id_get_data(), as would g_dbus_error_is_remote_error(). g_dbus_error_strip_remote_error() would become a deprecated no op. Will try to cook up a patch for this.
Sounds good to me - should also add const gchar *g_dbus_error_peek_remote_error (GError *error); for C convenience (where the pointer is only valid until @error is cleared).
Using datasets in this way to 'expand unexpandable structures' makes me uncomfortable...
Plus -- how would you propose this works in cases like g_prefix_error()?
(In reply to comment #3) > Plus -- how would you propose this works in cases like g_prefix_error()? I'd except functions modifying a GError in-place keeps the associated data. I'd also except g_error_copy() to do a deep copy of the associated data.
(In reply to comment #3) > Plus -- how would you propose this works in cases like g_prefix_error()? This new way works with g_prefix_error() really well. It's the previous "GDBus.Error:" g_dbus_error_strip_remote_error() stuff that didn't work with g_prefix_error(). The new solution also works with g_propagate_error() and g_propagate_prefixed_error(). (In reply to comment #2) > Using datasets in this way to 'expand unexpandable structures' makes me > uncomfortable... Hmmm. Why? That's what it's for. See the first paragraph of the description of the Datasets page. Well do an 's/external//' on the paragraph. :) (In reply to comment #4) > I'd > also except g_error_copy() to do a deep copy of the associated data. Well I haven't made that work in the patch I worked on so far. Currently the only modification to GError was adding a g_dataset_destroy(). But in order to accomplish the above, there would need to be further logic in GError.
Created attachment 225268 [details] [review] WIP: Don't prefix gdbus errors
Created attachment 225347 [details] [review] GError: Add concept of attaching an identifier to an error This will be used by GDBus to tag GError structures with its DBus error names, rather than changing the semantics of the human readable message strings.
Created attachment 225348 [details] [review] gdbus: Use g_error_set_identifier() to tag DBus errors Tag DBus errors with DBus error names using the new identifiers on GError structures rather than changing the semantics of the human readable message strings.
FWIW, these mangled error->message strings are showing up everywhere: https://bugzilla.redhat.com/show_bug.cgi?id=862333
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/610.