Maybe BlueZManager.get_default_adapter() should raise "BleakDBusError" instead of "BleakError".

[RyanNorge]

OK maybe this is way too pedantic, but I see an error being raised as a general "BleakError" that I'm wondering should maybe be a "BleakDBusError".

File...
/bleak/backends/bluezdbus/manager.py
Method...
BlueZManager.get_default_adapter()

The docstring says "Gets the D-Bus object path of of the first powered Bluetooth adapter." but it raises a general "BleakError".
Since this method is specifically about the D-Bus, shouldn't it raise a "BleakDBusError" instead?
I mean, you have an error class specifically about that. Isn't this the right place to use it?

I don't know enough about all this stuff to say, but it seemed strange to me. Anyways, thanks for the great library and for all the hard work :)

[dlech]

To be pedantic... 😄

A BleakDBusError wraps an error sent over the D-Bus message bus. So, for example, calling the D-Bus method org.bluez.Device1.Connect() could return org.bluez.Error.AlreadyConnected possibly along with some additional data. All D-Bus errors sent over the bus have a namespaced error name like this. (You can read more about it in the D-Bus spec if you are interested in learning more.)

It doesn't make sense to make up our own error names and use BleakDBusError just because it has to do with something related to D-Bus.

Another way of looking at it is that BleakDBusError is an extension of OSError for the BlueZ backend that we are propagating a backend-specific error. On the WinRT backend, we can get a WinError and on the CoreBluetooth we can get a NSError. Ideally, all of these OS-specific errors would be wrapped up in some kind of generic BleakError. But unfortunately, Microsoft and Apple don't document all of the possible error codes that can be returned by their method calls like BlueZ does, so we don't have a way to make cross-platform exception types. So we've just let these backend-specific exception types propagate so far.

[RyanNorge]

Gotcha. Thanks for the great response! As someone developing something cross-platform it's a big help that you've kept it consistent.

Often when you start poking around in unknown waters, things can seem strange at first, but you learn that smart and informed people have already made reasonable decisions before you came along.

This is just a great example of why it's nice to use a library. Thanks again for abstracting all that away so that the rest of us can have fun dancing on top of it all :)