[gst-devel] error explanation

[Benjamin Otte]

On Tue, 20 Jan 2004, Thomas Vander Stichele wrote:

> > - 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.
>
> I was pretty much 50/50 on this one.  I decided by thinking from the
> user's perspective, and thought that the user would rather see "could
> not encode format" or "could not decode format" than "format problem",
> since he understands the first two better.
> Of course, most users don't know what mux and demux are (and I thought
> about just making DEMUX DECODE and MUX ENCODE, since for the user
> they're probably the same anyway.  This is my preference atm)
>
The user will not see the category anyway - it's only interesting because
of the default message, right?

> > - 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.
>
> Yeah, it's awkward.  OTOH, the goal was to make it one function-like
> call, and we didn't find any other way to do this.  If you have a
> problem with the nestedness, we can do the same thing as the i18n
> macros, and just use something like E_() and D_() to achieve the same
> thing if this pleases you better.  Let me know.
>
Well, my idea is a function like this:

static void
gst_element_error (GstElement *element, GQuark domain, gint code, gchar
*message_format, gchar *debug_format, ...)
{
  gchar *message, *debug;
  va_list args, args2;

  va_start (args, debug);
  G_VA_COPY (args2, args);
  message = g_strdup_vprintf (message_format, args);
  debug = g_strdup_vprintf (debug_format, args2);
  va_end (args);
  va_end (args2);
  gst_element_error_extended (element, domain, code, message, debug,
__FILE__, GST_FUNCTION, __LINE__);
}

> > - GstError totally bypasses the debugging system. I'm never informed via
> > debugging output that a gst_element_error happened.
>
> gstelement.c:2406:
>   GST_CAT_INFO (GST_CAT_ERROR_SYSTEM, "signaling error in %s: %s",
>                 GST_ELEMENT_NAME (element),
>                 sent_message);
>
I was more thinking about something like adding a GST_ERROR_OBJECT (el,
debug); to the gst_element_error macro.

> Originally I didn't want to as I wanted to keep the function macro a
> true function replacement without using braces.  I had to change it
> anyway because the C++ plugins were complaining.  OTOH, I'm not sure if
> this is useful for anything.  What's the advantage ?
>
Nothing really important. It's just that I prefer functions that take
const arguments. People always get confused about wether functions take
ownership of arguments or not. And const ensures they don't :)

Benjamin