Errors and the introspection format
thiago.macieira at trolltech.com
Sun Feb 19 11:59:09 PST 2006
Havoc Pennington wrote:
>In other words, if a method claims to return a String, and the callee
>returns an integer, then it's the responsibility of the caller-side
>bindings to convert that into an error.
Since Introspection of the target is an optional feature, even though part
of the specification, I don't see how enforcing that in all bindings is
the correct thing to do.
What's more, the input parameters for methods and the output parameters
for slots constitute the signature. The output parameters for methods do
not. As so has been said in this thread, some bindings may not even
include the output arguments in the introspection data -- but that
doesn't mean they don't return any.
Therefore, it is currently up to the binding implementation to decide what
to do with unexpected parameters. In the example you provided, the
binding could just decide to convert the integer to a string. Untyped
languages may do this automatically, for instance.
In fact, the same may happen too to input parameters: automatic type
translation may happen on method calling on the callee side.
So, while I think this kind of detail should be left out of the D-Bus
specification (since introspecting the target before calling is not
mandated), I do think bindings themselves should explicitly tell their
users what they may do when unexpected data comes in, including errors.
>For exceptions, if we made the "throws clause" a part of the method
>signature, then bindings would need to convert any unexpected "checked"
>exceptions into some kind of DBUS_ERROR_UNEXPECTED_ERROR. We would not
>want to do this conversion for the "unchecked" exceptions like the
>communications errors and out of memory.
Which is why Matthew is asking for a list of what exceptions a method is
supposed to throw under normal operating procedures. Languages, bindings,
APIs and authors that don't like exceptions may still choose not to use
>So we would have to introduce some kind of "is this error checked or
>unchecked" concept, I don't even know where that bit would be stored,
>and then all bindings would need to do the appropriate signature
>verification to be sure only expected checked exceptions made it out.
As I illustrated above, I believe it's up to the binding implementation to
decide whether to enforce this or not. Unless, of course, the
specification is modified to mandate this.
>Which is why it would be much simpler to just only have unchecked
>exceptions in the first place, and not worry about it.
That's true, but it's up to the binding author to weigh what is the
simpler thing to do and what would be the best thing to do in his code.
>D-BUS calls are just like Java's Method.invoke(), they effectively throw
>InvocationTargetException because they are dynamic and the exceptions
>the callee will come up with can't be verified by the caller's compiler
>at compile time.
That's not exactly true.
We are talking about compile-time checking here (I think). The XML
description is processed into source code and then compiled. This is
something I am now writing and has been part of my plan since day 1.
And BTW, I've been using an annotation internally to indicate that a
method will not send a return message (even an empty one). Given the
discussion here on errors/exceptions, it looks like it's relevant to ask
if this should be standardised as an org.freedesktop.* annotation.
Yes, I am required to do that because there are many DCOP methods that are
asynchronous. So it's not a question of whether there will be such an
annotation, but rather if it should be an org.freedesktop.* one. And,
again, since return values are not part of the method signature, an
implementation can choose to ignore this completely.
Thiago José Macieira - thiago.macieira AT trolltech.com
Trolltech AS - Sandakerveien 116, NO-0402 Oslo, Norway
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/dbus/attachments/20060219/ad3d22b2/attachment-0001.pgp
More information about the dbus