From: Fabien Chevalier <fabchevalier@free.fr>
To: BlueZ development <bluez-devel@lists.sourceforge.net>
Subject: Re: [Bluez-devel] Some Audio error handling fixes.
Date: Sat, 13 Sep 2008 21:49:46 +0200 [thread overview]
Message-ID: <48CC195A.8000106@free.fr> (raw)
In-Reply-To: <1221325424.6695.45.camel@californication>
Hi Marcel,
>
> 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.
Ok, that might be quite a huge patch though... it has been that way for
so long... virtually every function will be impacted :-(
>
>> 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.
Ok i see the thing now. By that i guess that all error handling outside
of g_dbus_create_error are on their way out ?
I guess those ones should be replaced with g_dbus equivalents ?
./src/adapter.c:static DBusHandlerResult error_failed(DBusConnection *conn,
./src/adapter.c:static DBusHandlerResult
error_connection_attempt_failed(DBusConnection *conn,
>
> 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.
>
Thanks for the explanation,
Cheers,
Fabien
-------------------------------------------------------------------------
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
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel
next prev parent reply other threads:[~2008-09-13 19:49 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-13 15:54 [Bluez-devel] Some Audio error handling fixes Fabien Chevalier
2008-09-13 16:12 ` Luiz Augusto von Dentz
2008-09-13 19:08 ` Fabien Chevalier
2008-09-13 17:03 ` Marcel Holtmann
2008-09-13 19:49 ` Fabien Chevalier [this message]
2008-09-13 20:50 ` Fabien Chevalier
2008-09-13 20:57 ` Marcel Holtmann
2008-09-14 8:14 ` Fabien Chevalier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=48CC195A.8000106@free.fr \
--to=fabchevalier@free.fr \
--cc=bluez-devel@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox