[Bug 23369] [0.11] Make better use of telepathy-spec 0.17.27 errors
bugzilla-daemon at freedesktop.org
bugzilla-daemon at freedesktop.org
Tue Apr 27 17:33:34 CEST 2010
https://bugs.freedesktop.org/show_bug.cgi?id=23369
Simon McVittie <simon.mcvittie at collabora.co.uk> changed:
What |Removed |Added
----------------------------------------------------------------------------
URL| |http://git.collabora.co.uk/
| |?p=user/smcv/telepathy-glib
| |-smcv.git;a=shortlog;h=refs
| |/heads/even-better-errors
Status|NEW |ASSIGNED
Blocks| |21120
--- Comment #2 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2010-04-27 08:33:34 PDT ---
I finished off the branch as smcv/better-errors, and added another,
smcv/even-better-errors. The former is relatively safe, the latter less so.
I can divide the better-errors branch up into 3 parts (TpBaseConnection,
TpConnection, TpChannel Group) and get them reviewed separately, if one turns
out to be controversial. Branches on the way in a moment (currently rebasing,
since there were changes in the tests that are likely to conflict).
TpBaseConnection
================
When #TpBaseConnectionClass.start_connecting fails, any GError it yields is
turned into a Connection_Status_Reason. I just added some more cases. This
should be uncontroversial.
TpConnection
============
Old:
* Network_Error, "...ConnectionFailed" -> TP_ERROR_CONNECTION_FAILED
* Network_Error, "com.example.NoNetworkCoverage" -> TP_DBUS_ERROR_REMOTE_ERROR
New:
* Network_Error, "...ConnectionFailed" -> TP_ERROR_CONNECTION_FAILED
* Network_Error, "com.example.NoNetworkCoverage" -> TP_ERROR_NETWORK_ERROR
This also adds a function tp_connection_get_detailed_error(), which gets the
ConnectionError arguments (if that signal was emitted) or a D-Bus error string
chosen based on the invalidation reason (otherwise), and is necessary for Bug
#21120.
TpChannel Group (in better-errors)
==================================
This changes the TpProxy::invalidated error if a D-Bus error string is seen in
the "error" detail of MembersChangedDetailed. Previously, we used the
Channel_Group_Change_Reason to construct an error in
TP_ERRORS_REMOVED_FROM_GROUP; now, we use the "error", if recognised. If the
"error" is not recognised, we still fall back to the
Channel_Group_Change_Reason.
Old:
* Error, "...ConnectionFailed" -> domain=TP_ERRORS_REMOVED_FROM_GROUP,
code=TP_CHANNEL_GROUP_CHANGE_REASON_ERROR
* Error, "com.example.NoNetworkCoverage" ->
domain=TP_ERRORS_REMOVED_FROM_GROUP, code=TP_CHANNEL_GROUP_CHANGE_REASON_ERROR
New:
* Error, "...ConnectionFailed" -> TP_ERROR_CONNECTION_FAILED
* Error, "com.example.NoNetworkCoverage" ->
domain=TP_ERRORS_REMOVED_FROM_GROUP, code=TP_CHANNEL_GROUP_CHANGE_REASON_ERROR
TpChannel Group (in even-better-errors)
=======================================
This additionally changes the behaviour of TpChannel's TpProxy::invalidated
when there isn't an "error", or it isn't recognised. Instead of encoding the
Channel_Group_Change_Reason into TP_ERRORS_REMOVED_FROM_GROUP, it's now encoded
into TP_ERRORS, whenever possible, which makes TP_ERRORS_REMOVED_FROM_GROUP
mostly obsolete.
As a special case, Channel_Group_Change_Reason_Error turns into the
NotAvailable error code (I could change this if someone has a better idea).
Old:
* Kicked -> domain=TP_ERRORS_REMOVED_FROM_GROUP,
code=TP_CHANNEL_GROUP_CHANGE_REASON_KICKED
* Error, "com.example.NoNetworkCoverage" ->
domain=TP_ERRORS_REMOVED_FROM_GROUP, code=TP_CHANNEL_GROUP_CHANGE_REASON_ERROR
New:
* Kicked -> TP_ERROR_CHANNEL_KICKED
* Error, "com.example.NoNetworkCoverage" -> TP_ERROR_NOT_AVAILABLE
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
More information about the telepathy-bugs
mailing list