[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Reporting errors over QDBus?
From:       Thiago Macieira <thiago () kde ! org>
Date:       2006-10-27 18:28:56
Message-ID: 200610272029.07137.thiago () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


Tobias Hunger wrote:
>On Friday 27 October 2006 16:18, Andre Magalhaes wrote:
>> > How can I report that something went wrong in the class the adaptor
>> > is bound to? I could use return codes, but that feels rather clumsy.
>> > Is there some mechanism like an exception (maybe using QDBusError?)
>> > or am I stuck with using return codes only?
>>
>> No you can just append a QDBusMessage param to the end of the method's
>> param list and use it to set an error, see
>> QDBusMessage::createErrorReply and
>> http://doc.trolltech.com/4.2/qdbusdeclaringslots.html (Delayed
>> replies).

The documentation is a bit outdated. The Qt 4.2.0 final API requires you 
to use the function QDBusMessage::createErrorReply, like you said, but 
the format is slightly different.

You have to do:
	QDBusMessage error = msg.createErrorReply(.....);

>Doing that will prevent me from ever calling those methods directly,
> without DBus, doesn't it?

You can call them directly, but you need to:
a) pass something in the QDBusMessage argument
b) make sure that the method isn't going to try to 
msg.connection().send(...), delayed or not.

So, in other words, you need to make sure that there will be no error.

>For my unit tests (and since I have to use the methods locally) I need
> to be able to access the functionality of my methods directly.

Why? You can call them via D-Bus, even if locally. QtDBus allows you to do 
that.

> Going 
> the way you suggested would require me to write a wrapper-method that
> calls a method without the QDBusMessage, catches its exceptions (or
> whatever the non-DBus variation of the method uses to report errors)
> and turns them into DBus error messages. That is rather a lot of --
> error prone -- work. Surely there must be some simpler way to report an
> error?

The way to report error is to call createErrorReply. That's the only way 
and is not going to change.

>> All proxy methods return a QDBusError<ReplyType>, use it to check if
>> an error occured.
>
>Ah, I see!
>
>So I end up having to check each reply coming in over DBus for errors
> manually as the return values of DBusReply is undefined (and might be
>indistinguishable from a real value) when I do not. I had hoped all that
>happened in the interface class generated by qdbusxml2cpp:-(

QDBusReply<T> allows you to check whether an error occurred. It is what 
you're looking for. What else could the classes do? Abort the program? 
Throw an exception? Print something? None of those are valid options.

If you purposefully ignore the error condition and try to access the 
variables that would have contained the returned values, what would you 
expect?

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

[Attachment #5 (application/pgp-signature)]

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


[prev in list] [next in list] [prev in thread] [next in thread]