Repository navigation
Async method calls do not show/print exceptions #97
Description
If the exception occur in a method callback, the exception is not shown:
import asyncio
import sdbus
class Test(sdbus.DbusInterfaceCommonAsync, interface_name="org.test"):
@sdbus.dbus_method_async(result_signature="u")
async def open(self) -> int:
print("Open call")
raise ValueError("Nooo")
test = Test()
async def startup() -> None:
await sdbus.request_default_bus_name_async('org.example.test')
test.export_to_dbus("/")
loop = asyncio.new_event_loop()
loop.run_until_complete(startup())
loop.run_until_complete(asyncio.sleep(10))
print("Done")$ ./test.py
Open call
Done$ gdbus call --session --dest org.example.test --object-path / --method org.test.Open
Error: GDBus.Error:org.freedesktop.DBus.Error.Failed:It is visible on the client side that something was wrong DBus.Error.Failed, but it's hard to tell what was wrong. It would be nice to have a traceback printed in case of an exception in a D-Bus API handler (method or property). However, I'm not sure whether that is intentional or a bug?
As a workaround I can wrap method/property code in a try/except block, but I think that it would be nicer to have a traceback in case of non-DBus exception. If someone would like to return an error from a method/property, a dedicated DBus exception should be used. What do you think? Otherwise it's really, reaaaaalllyyy hard to debug issues (e.g. a simple typo) in a program based on sdbus library.
If not, the returned D-Bus error should at least have the ValueError's message included.
Setup
sdbus was installed via PIP:
$ pip freeze |grep sdbus
sdbus==0.13.0
Activity
igo95862 commentedon Mar 6, 2025
Hello @arkq
The exceptions in response handlers probably should be logged. I am planning on improving logging.
The strange part is that ValueError should be converted to the
org.python.Error.ValueErrorD-Bus error but it does not seem to be happening?arkq commentedon Mar 6, 2025
Definitely it would be nice to have some logs. However, on the other hand if someone raises exceptions intentionally, logging such events might not be necessary (or even unwanted). So, that's why my proposition of how to deal with intentional (D-Bus related) exceptions and unintentional (
ValueError,RuntimeError, etc.).EDIT:
Or maybe by default you can convert python exceptions to D-Bus exceptions, but allow user to "disable" that functionality. Allow exception mapping customization. So, if someone will not want any conversion, it should be possible to remove that mapping entirely. Then return generic D-Bus error, and log exception with
loggingmodule. Such feature will not break current behavior, but will add some flexibility.igo95862 commentedon Mar 26, 2025
I found the reason the Python built in exceptions do not properly get transformed in to the D-Bus errors. The error handling in messages callback is actually done is Python but never implemented the code to retrieve the exception mapped name if it is not a subclass of
DbusFailedError.igo95862 commentedon Mar 26, 2025
@arkq I added 01eb5d2 which should mean you would see something like this:
I haven't added logging right now but I think I will do that in the next version.