Re: Some Audio error handling fixes.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


Hi Fabien,

> While running tests on bluez-utils lately i found a number of big and
> little error handling issues.
> Attached patchset fixes all of them :-)
> Can anyone have a look to it ?

actually the convention is that if it is a return value, then we use a
negative error value. If it is a parameter, we use the positive one. So
the connection_lost change is wrong (it was wrong before though). Please
fix this too.

> While reading the latest code, i noticed common/error.{c, h} is gone...
> There's a new one in src/, but with only one generic
> error handling routine. I have the feeling this is a big step backwards,
> as DBUS error names get duplicated into each service
> again and again, paving the way for un unmanageable level of error
> strings fragmentation :-( What do you guys think ?

It is not a big step backwards since we are using libgdbus error
functions now and there are more simpler. There is a problem with the
strings returned for a specific error, but I don't really thing it is
that big of a problem.

In the long term we might get btd_error_* or alike functions since then
the plugins can use them. However right now every plugin has to handle
its own errors.



This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
Bluez-devel mailing list

[Index of Archives]     [Linux Bluetooth Devel]     [Linux USB Devel]     [Network Devel]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]

  Powered by Linux