[gst-devel] a general question re: error handling

[Andy Wingo]

On Mon, 30 Sep 2002, Thomas Vander Stichele wrote:

> I've been adding error handling to gst-player, and now I find myself in 
> the same situation for the editor.
> 
> If you start the editor, set the empty pipeline to play, then add an 
> element, the app crashes on an assert because you're adding to a playing 
> pipeline.
> 
> It'd be a lot nicer if it did
> http://thomas.apestaart.org/download/screenshots/gst-editor-warning.png
> instead.

I agree, although maybe phrased without the exclamation point ;-)

> Now, a few questions before I make Andy mad by adding all sorts of gtk 
> crap to the source ;)
> 
> a) should the core fail with an assert, or should it return from the _add 
> function with some sort of error state ? i.e., is the app responsible for 
> checking if the assert won't be triggered ?

In this particular case, are there any other reasons why an element
couldn't be added to a bin? If not, this is worth the logic in the
editor to check if the bin is in PLAYING or not, and complain
accordingly.

> IMO, we have used asserts liberally inside the core, which is a good 
> thing, but I believe asserts should only be used where they truely mean 
> "this is the responsibility of the app programmer to ensure this condition 
> never happens".  If this is the case, then some of those asserts may need 
> to be re-evaluated.

Correct.

> b) if it's the app's duty to do this, should we write a library that 
> handles this in a generic way for all apps to use ?

The editor seems to be somewhat special, in that its feature set is
close to identical to what gstreamer offers. I think we should just add
the necessary logic to the editor such that the user never sees a
GST_ERROR.

> c) should we start evaluating all of the core and apps to come up with a 
> sane way to handle feedback, warnings and errors in a sane fashion ?

Only for errors that are not programming errors.

Hm, this got me thinking about the gst-mask. OH ROCK! Ok, so Erik was
foresighted enough to allow for alternate debug, info, and error
handlers. We'll just have the editor define its own error handler, and
we're done! Provided, of course, that the relevant functions return
after calling GST_ERROR.

rawk!

wingo.