Errors and the introspection format

[Thiago Macieira]

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 
this feature.

>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
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/dbus/attachments/20060219/ad3d22b2/attachment-0001.pgp