[gst-devel] Error messages printed on console

[Benjamin Otte]

Quoting Thomas Vander Stichele <thomas at apestaart.org>:

> gst_element_error is not a good example of something stopping the
> application from working correctly.
> 
> Rather, GST_ELEMENT_ERROR is used when the *library* or *element* cannot
> proceed anymore.  The application can easily recover from this if it
> wishes to do so.  It is because of this distinction that I think that
> there is a clear difference between "errors that stop GStreamer from
> working completely" or "errors that stop GStreamer from further
> processing without intervention from the application".
> 
I agree, it should say something like "stops the part of code this category 
manages from working correctly".
Note that a debugging message is _never_ to be used for something that stops 
GStreamer from working correctly. It is purely a debugging message and as such 
merely informs about what the code does. We use g_warning and friends for 
things that prevent GStreamer from working.

> I am fine with the ERROR log level being used for GST_ELEMENT_ERROR
> logging, and even only for this (as long as we make it clear it is meant
> for errors that the application can still recover from).
> However, I see no reason to have them printed by default for development
> builds.  I don't mind going with a consensus on that, either, but some
> people have brought up they don't see why they get printed if the
> application already shows them in the GUI.
> 
My original idea for it was this: Whenever something happens to the part of 
the code that definitely should not happen in a normal situation and that you 
would want to know about, you use this category. Then if someone uses CVS, he 
will certainly mention that debugging line in the bug she files or the mail 
she writes. And it will even show up in a debugging log of a different 
category, because it's enabled.

Some other things:
gst_osselement_sync_parms uses g_warning when there are differences between 
requested and actual sound format. It should use GST_ERROR_OBJECT instead, so 
we don't wonder when someone complains about chipmunks audio. (It's certainly 
not a programming error when this happens.) This is an example where I 
wouldn't use GST_ELEMENT_ERROR, but GST_ERROR_OBJECT.
Server applications (like fluendo) will (hopefully) not signal errors to the 
user but handle them without anyone noticing. You probably still want to have 
an error log telling you about such things though. In that case using a custom 
debugging handler that logs errors to a logfile sounds like a good idea.


Benjamin