IDL language

[Simon McVittie]

On Mon, 11 May 2009 at 23:37:34 -0400, Havoc Pennington wrote:
> On Mon, May 11, 2009 at 11:07 AM, Matthew Johnson <dbus at matthew.ath.cx> wrote:
> > Havoc's point that there will always be unchecked exceptions which could
> > be thrown notwithstanding, some languages might want to make them
> > checked exceptions, so we shouldn't lose the information.
> 
> Even in languages with checked, though, some exceptions should be
> checked (those that need handling) and some should not (those that
> represent an unhandleable bug).

In Telepathy, the list of possible errors is purely documentation - "you should
expect to receive this error sometimes, and if you do, this is what it means
in this particular context" - like the way syscall/library man pages from the
Linux man-pages project list possible errno values and their interpretations
(see the ERRORS section of execve(2) for a good example).

telepathy-spec combines a pseudo-IDL with a lot of documentation - its primary
purpose is to document our D-Bus API, and the fact that we can generate
bindings from it is secondary.

We don't distinguish between errors that indicate "you are wrong, go
away" (like InvalidArgument) and errors that indicate "something went wrong,
sorry" (like NetworkError), although most of our error codes (including the
ones mentioned here) always have one or the other use (again, just like
errno - EINVAL always means you're wrong, ECONNRESET always means something
happened outside your control).

We also go to considerable lengths to ensure that undocumented errors can be
used, so people extending Telepathy can add more specific errors if there's
a serious need for them (in some cases this means adding a parameter to a
signal whose value is an error name, because failure is signalled by some
mechanism that isn't a method return).

High-quality code should be prepared to deal with any error, from any D-Bus
method, without aborting or crashing, because this is IPC and you shouldn't be
remotely crashable. However, the handling of unexpected errors (those not
mentioned in telepathy-spec/the IDL/whatever) could reasonably be quite
simplistic.

Regards,
    Simon