[Bug 23369] [0.11] Make better use of telepathy-spec 0.17.27 errors

[bugzilla-daemon at freedesktop.org]

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.