Re: [gst-devel] error handling in GStreamer

[Bastien Nocera <hadess hadess net>]

On Tue, 2003-09-16 at 19:06, Thomas Vander Stichele wrote: 
> We've started working on proper i18n'd error handling in GStreamer. 
> We're still unclear about some of the issues, so now is the time to
> chime in.
> 
> Here are the goals:
> 
> a) signal errors from core and plugins on elements using real GObject
> signals
> b) provide a specific enum (in a GError) against a canonical list of
> enums for error codes that we (hopefully) can keep media-agnostic.
> c) provide a translated string matching the enum code
> d) provide a debug string (non-translated) for further debugging.
> e) provide the element that first signalled the error
> f) make a patch set that is largely applicable to stable and head at the
> same time
> 
> In an application, the following would thus be possible:
> a) pop up an error dialog with an advanced button, where "advanced"
> would show (d) and (e), as well as source code file, line number,
> function

I don't like that one, I must say. If it's a programming error, it
should go as a g_warning, not be user-visible.

> b) have the application trap errors of a specific kind so that it can
> decide to try plan b instead of popping up a dialog

That sounds good, as long as the filtering is done on the application
side (ie. all the signals are still sent to the application, whatever
happens).

> c) have the application use available translated strings (from core and
> plugins) if it chooses to do so

> d) have the application be able to provide it's own error messages if it
> thinks it needs to, based on the enum

(aren't c) and d) basically the same?)

I'd rather see that in the application itself. For example, an error in
playback will be different if we have a video playback application, or a
webcam application (taking totem and vanity as examples).

> 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).

Things like device errors should be finegrained, is it a permission
error, the device isn't there, the media is damaged, etc.

> 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'd rather not see that. See gnome-vfs, we would just add more error
elements as we find things that need error messages.

> 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";

Exactly.

> c) the API for elements could be something like
>    gst_element_gerror (GstErrorType GST_ERROR_(type), gchar *message,
> gchart *debug);
>    since we want both strings to be printf-like if needed, this would
> also mean that
>    - gst_element_gerror takes ownership of the strings and frees them
>    - a typical call would look like
>      gst_element_gerror (GST_ERROR_DEVICE,
>                          g_strdup_printf (_("%s not accessible",
>                                           device),
>                          g_strdup_printf ("no write permissions on %s",
>                                           device));

Either that code will leak, or it will crash when I pass non-malloc'ed
strings ;)

> 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

I really don't like the idea of debug info being presented to the user.

> As for the translations itself; the core would contain a hopefully
> exhaustive list of error enums, and code to map between enums and
> translatable strings.  The translations would probably live in gnome cvs
> and get regularly sinked to core until the time we can move cvs.

As long as the application can provide its own translations and error
messages, I'm all for it.

Cheers

--

Bastien Nocera <hadess hadess net> 

Her artistic sense was exquisitely refined, like someone who can tell
butter from "I Can't Believe It's Not Butter."