[Telepathy] Our error reporting sucks

[Dafydd Harries]

Ar 28/08/2008 am 16:45, ysgrifennodd Olivier Cr??te:
> Hello,
> 
> After spending too much time already trying to debug errors coming out
> of a connection manager, I've come to a simple conclusion: Telepathy
> error reporting SUCKS! 
> 
> As a first step, I propose adding translated error strings to the dbus
> errors.. So that instead of getting only "NetworkError", we'd also get a
> strings that says "Could not resolve a.b.c". Obviously, the UIs could
> ignore the string and the CMs don't have to emit a message with every
> error.

How exactly do you propose we add an extra string? In the case of D-Bus method
return errors, there isn't a place for us to put extra structured data. In the
case of asynchronous errors, I don't see how to do without breaking API in a
pretty nasty way.

I don't really like the idea of adding translations to connection managers.
Either error conditions are common, in which case we should standardise them,
or they're uncommon, in which case they should stay in the form of debug
information. The problem is that we've been using integer enumerations of
error conditions, which are difficult to extend in ABI-preserving ways.

> Also replace the org.freedesktop.Telepathy.Connection.StatusChanged
> signal with StatusChangedMessage(uus) where the string is the reason for
> the status change (I'm especially thinking of the NetworkError reason
> here). 
> 
> Also, I propose adding new log retrieval interface and make it mandatory
> on the ConnectionManager object and optional on the sub-objects (the
> Connection and Channels).
> 
> Something like org.fd.tp.LogRetrieval with this method:
> GetLog(u: Number of Lines to return u: Min log level) -> a(us)
> Where u would be the log level for that line (and s the string)
> so the UI can display/colorise it properly.

This is a good idea, but I think probably a per-service debug object is easier
to interface with. I think it should probably be something like:

  EnableDebugging() -> a(us)

I'm not sure the minumum log level parameter is very useful: you can filter
that out on the client side. Also, calling this function would make a D-Bus
signal be emitted for each debug message. This means that a debugger can watch
a session without having to poll for logs. It might even be possible for
dying services to send assertion failure messages over the bus.

I think each service should probably have a global debug object. 

-- 
Dafydd