logs an error and traceback when some other program requests an unknown property

[foresto]

When some other program on the bus tries to access a nonexistent property on a dbus-next service, BaseMessageBus currently raises an exception, and handles it by writing both a log message and a stack trace at the ERROR log level.

For example:

got unexpected error processing a message: interface "org.kde.StatusNotifierItem" does not have property "IconThemePath".
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/dbus_next/message_bus.py", line 621, in _on_message
    self._process_message(msg)
  File "/usr/lib/python3/dist-packages/dbus_next/message_bus.py", line 712, in _process_message
    handler(msg, send_reply)
  File "/usr/lib/python3/dist-packages/dbus_next/message_bus.py", line 898, in _default_properties_handler
    raise DBusError(
dbus_next.errors.DBusError: interface "org.kde.StatusNotifierItem" does not have property "IconThemePath"

That's a lot of noise to have spamming my application's (and users') logs. I could silence it by disabling all dbus-next logs below CRITICAL, but then I would miss any legitimate errors if they come up.

Since an external program requesting an invalid property is not a bug in the program using dbus-next, shouldn't the log message be downgraded to DEBUG or INFO level? And shouldn't the stack trace be removed entirely?

And, if the library is going to log anything, shouldn't it also log which dbus sender tried to access the nonexistent property?

[elParaguayo]

Not a solution to your problem (and you may not get one as the package seems to be unmaintained...), however I've written a StatusNoifierHost app and I check every StatusNotifierItem for the Menu property. It is part of the spec and I've not come across an app that hasn't provided it.

Why not just provide an empty string?

I do appreciate the above was just an example so your issue remains valid.

[foresto]

Not a solution to your problem (and you may not get one as the package seems to be unmaintained...),

I'm not looking for a solution for my own code. I can work around it in the current situation. However...

Why not just provide an empty string?

I reported this because it's a general problem. It doesn't apply only to the Icon property. (Note that I updated my example to show the same thing happening with an IconThemePath property, which is not in that interface's spec.) More importantly, it doesn't apply only to this particular interface.

It applies any time an external program tries to access something that isn't there, whether it's in (some version of) a spec or not. Users of this library shouldn't be burdened with spurious error logs and stack traces just because some other software, outside of our control, happens to be impolite. :)

[elParaguayo]

Yeah, that's totally fair (and I've come across the issue myself). However, as this package seems to be unmaintained, I doubt you'll see anything change any time soon.