On Thu, 2012-02-16 at 14:41 +0100, Patrick Ohly wrote:
> Speaking of errors returned by the peer:
>
> Return_t sendAndReturn(DBusMessagePtr &msg)
> {
> DBusErrorCXX error;
> // Constructor steals reference, reset() doesn't!
> // Therefore use constructor+copy instead of reset().
> DBusMessagePtr reply =
> DBusMessagePtr(dbus_connection_send_with_reply_and_block(m_conn.get(),
> msg.get(), -1, &error));
> if (!reply) {
> error.throwFailure(m_method);
> }
> return CallTraits::demarshal(reply, m_conn);
> }
[...]
> "reply" may be an error message. That must be checked instead of trying
> to extract return values that won't be there.
Actually, it is okay for dbus_connection_send_with_reply_and_block(),
which already checks for an error reply.
It's g_dbus_connection_send_message_with_reply_sync() which doesn't do
that for us. Fixed:
Author: Patrick Ohly <[email protected]> 2012-02-16 15:15:30
Committer: Patrick Ohly <[email protected]> 2012-02-16 15:15:30
Parent: 99e9002e1a7d9804490a9cc16f168bebc145402d (GDBus GIO+libdbus:
revert the getConnection() patch)
Branch: cssr1
Follows: syncevolution-1-2-2
Precedes:
GDBus GIO: added missing error handling in blocking call operator
g_dbus_connection_send_message_with_reply_sync(), in contrast to
dbus_connection_send_with_reply_and_block(), doesn't convert a D-Bus
error reply message into a local error. This has to be done by
our own code before trying to extract the return values.
I've pushed it to the cssr1 branch.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution
