Re: [gst-devel] error handling in GStreamer

[Thomas Vander Stichele <thomas apestaart org>]

On Tue, 2003-09-23 at 17:54, in7y118 public uni-hamburg de wrote:
> Quoting Thomas Vander Stichele <thomas apestaart org>:
> 
> > f) make a patch set that is largely applicable to stable and head at the
> > same time
> > 
> I'm really interested how big the part is that works for both branches :)

me too; I think it will be fairly large.

> > some things to consider here:
> > a) we can provide functions that map the very specific finegrained enums
> > to coarse enum domains (ie, all device errors could map to one class).
> > 
> Let's take a look at GTK and use the same model. Both models sound useful. We 
> might even want to ask in #gtk+ about this.

Yeah, maybe.  Don't know if GTK has a lot of these though; where are
they defined ?


> > c) who knows best what went wrong, the element or the app ? A good
> > example to question is this:
> >   - if a plugin gives the translatable string, then it can pass along
> > what resource failed, ie which file was not found.  if an app does it,
> > it can know what resource it wanted to access, and thus provide a more
> > human way for the resource, ie "Could not listen to URGent radio"
> > instead of "could not open URL http://cleo.rug.ac.be:8000/mix";
> > 
> Well, an application is free to change an error if it knows better (like in 
> your example). Just as in GTK where you are free to make "could not load icon 
> image" out of GDKs "invalid image data" out of GDK-pixbufs "invalid byte 
> sequence" (that was invented, but you get the idea).
> This shouldn't free us from the burden of providing a useful error though. And 
> we might want to add errors in an update, when the app is not updated and would 
> not know what to say then.

Yep, agreed.

> The translated error cannot be NULL, because it's inside a GError and GErrors 
> require a non-NULL string. And I don't think it makes sense to allow "I'm too 
> lazy to translate" NULL strings either.

"NULL" would mean "use the generic error message (translated) inside the
core", because it describes best what this error is, and the plugin has
no need to add to it or change it.  Whether this gets mapped before
sending a GError or after is an implementation detail; given your
arguments I would implement it as being mapped before the error gets
signaled.  Is that better ?

Thomas


Dave/Dina : future TV today ! - http://davedina.apestaart.org/
<-*- thomas (dot) apestaart (dot) org -*->
If I was twice the man I could be
I'd still be only half of what you need
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.rug.ac.be/