Errors and the introspection format

[Havoc Pennington]

On Sun, 2006-02-19 at 13:44 +0100, Thiago Macieira wrote:
> Further along that line, would it make sense to have an annotation meaning 
> "this doesn't throw anything, nor ever will?"

Another thing to keep in mind, for this to have meaning the caller not
callee has to enforce it.

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.

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.

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.

All this complexity would serve only to convert an unexpected checked
exception into an unchecked exception. You'd still have an exception,
and the app programmer still wouldn't be expecting it.

Which is why it would be much simpler to just only have unchecked
exceptions in the first place, and not worry about it.

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.

Havoc