Re: [systemd-devel] Reasoning behind sd_bus_error argument to sd_bus_call?
On Mi, 18.03.20 12:14, Daan De Meyer (daan.j.deme...@gmail.com) wrote: > I completely agree that for errors returned by the service, a D-Bus error > is a lot better. However, from what I understand of sd-bus, any errors > returned by the service are encoded in the reply returned by sd_bus_call > and you use sd_bus_message_is_method_error and sd_bus_message_get_error on > the reply to get the actual service error. Where does that leave the > sd_bus_error argument of sd_bus_call? We *either* return an error and fill in sd_bus_error (on error) *or* we return a reply msg (on success). i.e. you won't get an sd_bus_message object from sd_bus_call() at all on error, hence nothing you could look into with sd_bus_message_get_error(). Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Reasoning behind sd_bus_error argument to sd_bus_call?
I completely agree that for errors returned by the service, a D-Bus error
is a lot better. However, from what I understand of sd-bus, any errors
returned by the service are encoded in the reply returned by sd_bus_call
and you use sd_bus_message_is_method_error and sd_bus_message_get_error on
the reply to get the actual service error. Where does that leave the
sd_bus_error argument of sd_bus_call? Is it simply another way to get the
error? It seems to be always be set when a local or remote error occurs,
but it can only contain information that I can get by checking the return
value of the function or by checking whether the reply object passed to
sd_bus_call contains an error.
How I would imagine using sd_bus_call:
r = sd_bus_call(..., reply, ...);
if (r < 0) {
// Local error
}
if (sd_bus_message_is_method_error(reply)) {
const sd_bus_error *error = sd_bus_message_get_error(reply);
// Service error
}
But if this is the intended usage, what's the use of the sd_bus_error
argument of sd_bus_call since the above code already handles both the local
error and the remote service error failure paths?
Daan
On Wed, 18 Mar 2020 at 11:57, Simon McVittie wrote:
> On Tue, 17 Mar 2020 at 20:17:05 +0100, Daan De Meyer wrote:
> > I'm documenting sd_bus_call and its async variant and I was wondering
> about the
> > sd_bus_error output parameter that's passed to it. [...] I don't
> > see immediately see the benefit of the sd_bus_error parameter in a D-Bus
> client
> > since I can simply check the return value instead which seems to contain
> the
> > same information looking at the implementation.
>
> The return value is a single int, which according to systemd conventions
> is probably a negative errno value. That's a lot less information than
> a D-Bus error (systemd sd_bus_error, libdbus DBusError or equivalent):
> D-Bus errors consist of a machine-readable name (namespaced by a reversed
> domain name) and a human-readable message.
>
> For the information about *whether* an error occurred, sure, you get the
> same information, but for information about *which* error occurred and why,
> a sd_bus_error is a lot better.
>
> Let's pretend your D-Bus client is interacting with a D-Bus service that
> resembles systemd-timedated. An errno value can give you, at best,
> something like this (where *** marks the part that came from the service's
> reply):
>
> my-client: Error: Unable to set time zone to America/Gotham:
> ***No such file or directory (errno 2)***
>
> whereas a D-Bus error (sd_bus_error) from a well-implemented service can
> give you something a lot more detailed. For example, after you ispect
> the sd_bus_error, you might find that the error above was either of these:
>
> my-client: Error: Unable to set time zone to America/Gotham:
> ***No time zone file for "America/Gotham" found (tried
> "/usr/share/zoneinfo/America/Gotham",
> "/usr/local/share/zoneinfo/America/Gotham")
> (error code com.example.NotTimedated.Error.NoSuchTimezone)***
>
> my-client: Error: Unable to set time zone to America/Gotham:
> ***No time zone data installed (tried "/usr/share/zoneinfo",
> "/usr/local/share/zoneinfo")
> (error code com.example.NotTimedated.Error.TzdataNotInstalled)***
>
> In this example a programmatic client would also be able
> to respond differently to the distinct machine-readable
> errors com.example.NotTimedated.Error.NoSuchTimezone and
> com.example.NotTimedated.Error.TzdataNotInstalled if it wanted to;
> for example it could respond to the second error by trying to use
> PackageKit to install tzdata, which obviously wouldn't be appropriate
> for the first error.
>
> D-Bus errors were inspired by GLib's GError, which is basically a triple
> { domain: interned string, code: int, message: string }, where the domain
> provides extensible uniqueness, and the code is a member of an enum
> determined by the domain.
>
> smcv
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Reasoning behind sd_bus_error argument to sd_bus_call?
On Tue, 17 Mar 2020 at 20:17:05 +0100, Daan De Meyer wrote:
> I'm documenting sd_bus_call and its async variant and I was wondering about
> the
> sd_bus_error output parameter that's passed to it. [...] I don't
> see immediately see the benefit of the sd_bus_error parameter in a D-Bus
> client
> since I can simply check the return value instead which seems to contain the
> same information looking at the implementation.
The return value is a single int, which according to systemd conventions
is probably a negative errno value. That's a lot less information than
a D-Bus error (systemd sd_bus_error, libdbus DBusError or equivalent):
D-Bus errors consist of a machine-readable name (namespaced by a reversed
domain name) and a human-readable message.
For the information about *whether* an error occurred, sure, you get the
same information, but for information about *which* error occurred and why,
a sd_bus_error is a lot better.
Let's pretend your D-Bus client is interacting with a D-Bus service that
resembles systemd-timedated. An errno value can give you, at best,
something like this (where *** marks the part that came from the service's
reply):
my-client: Error: Unable to set time zone to America/Gotham:
***No such file or directory (errno 2)***
whereas a D-Bus error (sd_bus_error) from a well-implemented service can
give you something a lot more detailed. For example, after you ispect
the sd_bus_error, you might find that the error above was either of these:
my-client: Error: Unable to set time zone to America/Gotham:
***No time zone file for "America/Gotham" found (tried
"/usr/share/zoneinfo/America/Gotham",
"/usr/local/share/zoneinfo/America/Gotham")
(error code com.example.NotTimedated.Error.NoSuchTimezone)***
my-client: Error: Unable to set time zone to America/Gotham:
***No time zone data installed (tried "/usr/share/zoneinfo",
"/usr/local/share/zoneinfo")
(error code com.example.NotTimedated.Error.TzdataNotInstalled)***
In this example a programmatic client would also be able
to respond differently to the distinct machine-readable
errors com.example.NotTimedated.Error.NoSuchTimezone and
com.example.NotTimedated.Error.TzdataNotInstalled if it wanted to;
for example it could respond to the second error by trying to use
PackageKit to install tzdata, which obviously wouldn't be appropriate
for the first error.
D-Bus errors were inspired by GLib's GError, which is basically a triple
{ domain: interned string, code: int, message: string }, where the domain
provides extensible uniqueness, and the code is a member of an enum
determined by the domain.
smcv
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Reasoning behind sd_bus_error argument to sd_bus_call?
Hi, I'm documenting sd_bus_call and its async variant and I was wondering about the sd_bus_error output parameter that's passed to it. Is it specifically meant for use cases where we're doing a nested D-Bus method call from a service so we have an error object to send back from the initial D-Bus method call? I don't see immediately see the benefit of the sd_bus_error parameter in a D-Bus client since I can simply check the return value instead which seems to contain the same information looking at the implementation. Regards, Daan De Meyer ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
