[gst-devel] error handling in gstreamer

[Wim Taymans]

On Mon, 2003-06-02 at 14:12, Benjamin Otte wrote:
<snip>
> > 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.

For this, I feel that you need to report a code and some data to the
application instead of generating a message in the plugin.

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

Looking at (some of) the requirements:

1) an id (number) that gives an error domain (GError does that)
2) a string describing the error
3) extra data (for example for _LINK errors, the caps that failed)

1 and 2 are rather obvious and GError can do that.
3 is somewhat harder, not having it would rule out thomasvs's
requirement to report to the user that some plugin could not negotiate a
two channel audio connection. But I feel these kind of error messages
are bit too technical. 3 is however implementable without extra info in
the error message (provided the pad that trigered the nego failure is
marked as the src object in the error signal).

Do we also need something like a gst_element_info callback (a warning
that feature XYZ is not enabled, for example)? can we fold error and
info into a more general gst_element_message? if we do that can we use
GError for info messages? Do we need GstMessage?

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

Yes, exactly. Divide the pipeline into functional parts to allow more
specific error messages.

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

You could also add a "details >>" button to expand the error box and
show the internal (non translated) gstreamer error message. i18n can be
fully implemented for the messages associated with the error codes.

> 
> Benjamin
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: eBay
> Get office equipment for less on eBay!
> http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>