Draft: Expose GError codes from RInstallError via dbus #1635
Conversation
80193e7 to
dd0e307
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #1635 +/- ##
==========================================
+ Coverage 84.27% 84.28% +0.01%
==========================================
Files 71 71
Lines 22037 22052 +15
==========================================
+ Hits 18571 18586 +15
Misses 3466 3466
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
jluebbe
left a comment
There was a problem hiding this comment.
For the short/synchronous D-Bus calls, I prefer to return the error via D-Bus directly, but's that's not possible for installations, which are only triggered via D-Bus.
If @ejoerns fine with this approach, we'd need a list of the possible error codes in the documentation and perhaps we should use explicit numbering for the enum.
include/install.h
Outdated
| GQuark r_install_error_quark(void); | ||
|
|
||
| typedef enum { | ||
| R_INSTALL_ERROR_NOERROR, |
There was a problem hiding this comment.
This changes the existing error codes, but the shouldn't be exposed yet. @ejoerns?
Perhaps we can use -1 for R_INSTALL_ERROR_NOERROR?
There was a problem hiding this comment.
The compiler does not guarantee a specific enum number unless specified right?
There was a problem hiding this comment.
I've not researched it again, but I think in practice it starts at 0 and counts up.
There was a problem hiding this comment.
I pushed to my fork and now made NOERROR explicitly -1.
src/service.c
Outdated
| r_installer_set_last_error(r_installer, message); | ||
| } | ||
|
|
||
| void set_last_error_code(const int32_t code) |
There was a problem hiding this comment.
Perhaps let set_last_error() handle this as well by adding an argument?
There was a problem hiding this comment.
Can do. Could also just have it accept a GError as an argument.
There was a problem hiding this comment.
Hmm, yes. In that case, we also need to have a way to clear it, perhaps by passing NULL as the GError* argument.
73d5735 to
f8878f3
Compare
Let's dbus clients query the error codes that occur during installation. The RInstallError enum already defines error codes that are used throughout the installation process.
f8878f3 to
4cfa7b8
Compare
|
Well, it isn't that easy and I would still consider my comment in #690 valid:
The Glib errors you can get and would set in With the current code and handling there is no way to guarantee that As much as I would like to see the situation with end-user error reporting improved, I don't think it's an easy task to do. Because as soon as we expose them, they become an API and thus must remain stable. A feasible way I could think of is to map all errors to a generic "Installation Failed" code first and step by step identify and catch GErrors the user might benefit from when being able to distinguish them from the generic error. Then map these errors to distinct error codes. Thinking of this, I notice the 'high-level error' is something that we already have. It's the
These could easily be extended I guess. Even since it gets the most errors directly from the |
Let dbus clients query the error codes that occur during installation.
There are no error codes exposed via Dbus to the user. See #690.
The
RInstallErrorenum declared ininclude/install.halready defines error codes that are used throughout the installation process. Let's expose its value via dbus asLastErrorCode.The goal of this feature is to allow applications to understand error states better without having to rely on string parsing.
I ran
./uncrustify.shandmeson test -C buildas requested by the contribution guidelines.I have marked this a draft first as I would like to have feedback on what is missing here, aka examples, documentation?