Re: [gst-devel] error handling in GStreamer

[in7y118 public uni-hamburg de]

Quoting Thomas Vander Stichele <thomas apestaart org>:

> f) make a patch set that is largely applicable to stable and head at the
> same time
> 
I'm really interested how big the part is that works for both branches :)

> some things to consider here:
> a) we can provide functions that map the very specific finegrained enums
> to coarse enum domains (ie, all device errors could map to one class).
> 
Let's take a look at GTK and use the same model. Both models sound useful. We 
might even want to ask in #gtk+ about this.

> b) we need to decide on whether or not we want plug-ins to be able to
> provide custom translated messages.  If there is a direct one-to-one
> mapping between enums and error strings, this is not really necessary. 
> If the enum would be coarse-grained (ie, only apply to a domain, like
> GST_ERROR_DEVICE), then the element needs to be able to give more
> specific data.
>
I want that. (see above)

> c) who knows best what went wrong, the element or the app ? A good
> example to question is this:
>   - if a plugin gives the translatable string, then it can pass along
> what resource failed, ie which file was not found.  if an app does it,
> it can know what resource it wanted to access, and thus provide a more
> human way for the resource, ie "Could not listen to URGent radio"
> instead of "could not open URL http://cleo.rug.ac.be:8000/mix";
> 
Well, an application is free to change an error if it knows better (like in 
your example). Just as in GTK where you are free to make "could not load icon 
image" out of GDKs "invalid image data" out of GDK-pixbufs "invalid byte 
sequence" (that was invented, but you get the idea).
This shouldn't free us from the burden of providing a useful error though. And 
we might want to add errors in an update, when the app is not updated and would 
not know what to say then.

> d) my current idea is that it should work like this:
>   - use the API just shown (with the two strings)
>   - the plugin decides to either:
>     - provide a specific translatable UI string for this error
>     or
>     - use NULL as this string
>   - the application connects to the signal, and chooses to
>     - based on the enum, work around the problem somehow (try another
> device, another file, ...)
>     - if it does show the error, it checks if the translated string is
> NULL or not
>       if NULL, either show the generic error for this or show it's own
> translated string for it
>       if non-NULL, show the error passed along
>     - behind the advanced button, the debug output can be shown
> 
The translated error cannot be NULL, because it's inside a GError and GErrors 
require a non-NULL string. And I don't think it makes sense to allow "I'm too 
lazy to translate" NULL strings either.


Benjamin