[Telepathy] Our error reporting sucks

[Prasad]

> First, thank you for answering, although with a 3 months delay!
>    

:)
Great to see a discussion on error reporting!

>>> 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.
>>      
>
> Well, for dbus error, there is already a string parameter, isn't there ?
> And this isn't structured data, its a string...
>
> Async errors have been done wrong, accept it, break the API/ABI and fix
> it. Or for every case add a new signal "SignalNameWithUsableError" and
> then new clients can use these and old ones use the old one (that can
> all be abstracted by tp-glib).
>    

UI may not always be interested in getting these signals, so we should 
probably leave it to the user-interfaces to choose which messages they 
will want to see.  Something like a GetLastErrorString call could be 
more useful.


>> 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.
>>      
>
>
> If we want to avoid translated strings in the CM (I don't really see
> why, they run in the same desktop session as the rest of the crap). We
> can add LOTS more stuff to the error enum. But to make it useful, we
> still need a string with extra information (like if we had an error
> "can't resolve", then we'd also add a string with the hostname).
> Anyways, the current API is broken and needs fixing
>
>
>    

I think that the translated strings should be at the CM.
Unless we have the translated strings at the CM, we will need "standard" 
strings across connection managers.  Also, the extra information cannot 
be added unless we use structured data (pass an array that can do some 
substitutions in the translated string - like the printf)


Prasad,
Spicebird Project