[gst-devel] error explanation

[Benjamin Otte]

Ok, I have some issues with this. I'll list them in no order at all.

- GST_STREAM_ERROR_DECODE, GST_STREAM_ERROR_ENCODE,
GST_STREAM_ERROR_DEMUX and GST_STREAM_ERROR_MUX imply a function of the
element. All of these are basically just "format could not be read"
depending on the type of element. I think this should be the same error.

- gst_element_error is the only function inside libc, glib and GStreamer
that takes nested brackets. That's a style issue for me. The
*_CALL_PARENT macroes do that, too and it annoys the hell out of me. This
is C and not Lisp.

- I'm not sure if abbreviating error domains and codes is a good idea.
It's especially bad when grepping.

- gst_element_error sacrifies type checking for simplicity by simply
casting its first argument to a GstElement, no matter what. I'm not sure
it should be done that way. All other functions take the exact argument
for a reason (and casting GstElements to GstBins everytime you call
gst_bin_add needs to be done, too...). This is more a general "should we
always or never use gpointer instead of GstSomeType *" question.

- GstError totally bypasses the debugging system. I'm never informed via
debugging output that a gst_element_error happened.

- There is no clear requirement that debugging messages should include
stuff that has already put into the error message, so that the debugging
message is complete and understandable by the developer.

- I'd let gst_element_error_extended (glib would have used "_full"
there...) take const message and debug strings and let gst_element_error free
them.


Benjamin



On Mon, 19 Jan 2004, Thomas Vander Stichele wrote:

> Hi,
>
> I commited a short explanation of the error stuff.  I attached it as
> well so you don't have to go hunting for it.
>
> Some things still left to do:
>
> a) NULL for message/debug will probably have to change to (NULL), but
> I'd like access to different archs/compilers to check.
> b) all errors marked TOO_LAZY need to move.  I have a good idea where I
> want to move them, but I can also guess some people won't agree.  That's
> why I'd like the plugin owners to look at their elements and let me know
> how the errors marked TOO_LAZY would be classified according to them.  I
> prefer to do this without adding (too much) error codes.
> c) One thing I was sort of undecided on; if an element uses bytestream
> and gets a read error, should this be a STREAM error or a RESOURCE error
> ?
> d) Another thing I was undecided on; is a failure at encoding a stream a
> LIBRARY error or a STREAM error ? Should it be seen on a case by case
> basis, ie LIBRARY when it is the library which is clearly at fault, and
> STREAM when something in the stream is not correct and cannot be encoded
> ?
>
> Thomas
>
> Dave/Dina : future TV today ! - http://www.davedina.org/
> <-*- thomas (dot) apestaart (dot) org -*->
> Ten generations of selective cross-breeding
> and you still have a fat ass ?
> <-*- thomas (at) apestaart (dot) org -*->
> URGent, best radio on the net - 24/7 ! - http://urgent.fm/
>
>