[gst-devel] error handling in gstreamer

[Benjamin Otte]

On 31 May 2003, Thomas Vander Stichele wrote:

> While testing this, it pointed out a very obvious problem.  I selected
> "chart" from the menu of vis stuff, set to play, and got the error
> "could not negotiate format".
>
> As Julien told me, this is because chart only does mono.  So chart needs
> fixing.  But the bigger issue is, this error message is totally crap.
> It's completely useless because it doesn't help neither the user nor us
> as developers to figure out what goes wrong.
>
To emphasize what Ronald said: A plugin should only take caps it supports.
Everything else is the job of converters and autopluggers.
Please do not make plugins more difficult by forcing them to support
formats that are common.
(Other examples of that would be wavparse / wavenc and them taking only
little endian audio or Iains soundcard.)

> What the error message SHOULD say is something like "vorbisfile: could
> not connect stereo to mono between vorbisfile and chart", or something
> to that effect.  That would be a useful error message because it can be
> reported back to us for fixing.
>
The message of gst_element_error is meant as a debugging message and
should therefore not be translated at all, just like GST_DEBUG should not
be translated. Most of these messages would have to be quite different
and worse for the developer if they were rewritten to a user level anyway.
It's basically the same as a GError and I've been told they're not
translated either.

> Now, the question is, how do we get the relevant data out of the core to
> the UI ?
>
I would propose two simple changes:
1)
Let gst_element_error not return an string, but a GError.
This would not increase code size (glib already implements it) and it
would give us the possibility to specify different error domains (for
example GST_ERROR_LINK, GST_ERROR_INVALID_DATA,
GST_ERROR_HARDWARE_INTERACTION) which could be evaluated by applications
and we could still keep our error messages.
2)
Make libgstplay's error detections more intelligent by not only
connecting to the main pipeline but to different elements / bins. So if it
gets an error from spider it's most probably "does not support format", if
it's an error from the visualization part of the pipeline we might suggest
to turn of visualization and if the audio part complains it's most
probably a soundcard issue.

An added benefit is that we don't need i18n :)

Benjamin