Re: [gst-devel] error handling in GStreamer

[in7y118 public uni-hamburg de]

Quoting Bastien Nocera <hadess hadess net>:

> > I've gotten a lot of "if it's a programming error".  The simple fact is
> > that I've never regarded errors as either "programming" or "user"
> > errors.  Especially for multimedia apps/libs, this is a wrong
> > distinction to make.  Consider:
> > a) a user tries to play a video file
> > b) GStreamer tries to detect type and play it
> > c) Suppose gst gets the type wrong and can't play the file.  The user
> > will get a popup saying "This file cannot be played/is broken/...".  The
> > user tries with some other app, and it plays.  What went wrong ?
> > d) Suppose gst gets the type right, but there is some error in the file
> > and it can't decode it properly.  User gets the same popup.  It plays
> > mostly fine in another app.  What went wrong ?
> 
> You just need more fine-grained errors then.
> 
I thought about that a lot, too. And I think the "There's only user error or 
application error" point of view makes sense for GUI apps, but this concept is 
based on GUI apps.
See, your average GUI app gets an event from the X server and reacts to it. So 
if something goes wrong when reacting to the event, you can pretty much figure 
out from the event and the state of your app what went wrong.
But unfortunately GStreamer has a different way of working: It is possible for 
GStreamer to do stuff for hours without user interaction. So the bug report 
will most likely be "I pressed play, waited an hour and then got this error." 
instead of "After marking this element and performing that operation, the 
result wasn't what I expected.", which is not very helpful for us.

The error will most likely be recoverable (clean up the pipeline, start over) 
and in most cases does not require a bug report because it is an easily 
detectable user error. So you can't automagically pop up bug buddy to file a 
bug with that debug output attached unfortunately. You have to make it possible 
to provide all this information to the user and allow him to decide if filing a 
bug is the correct thing to do.

Suppose a filesrc ! demuxer ! decoder pipeline and the decoder spitting out an 
error. Was that because the demuxer has a programming error or because filesrc 
read an invalid file? How do you know from "invalid data"? You only get an idea 
by getting the file _and_ the detailed error message "Looking at position 0x3F 
of header reported ID 0xFFFF instead of 0x7A2B", that the demuxer is not 64bit 
safe and overwrites bounds in a memcpy on the users Itanium.
(note: bug constructed ;))

> That should be appearing in the debug info, on the command-line.
[...]
> You would tell the user: "Turn on debugging in the application, try
> playing it again, and send us the output". Even xine is very quiet these
> days when it comes to outputting debug.
> 
"Could you please restart your AVI with debugging enabled and wait another hour 
and hopefully reproduce the error?"

> When we get to the point where we have 5 webcam applications, I'll start
> worrying ;)
> 
We're clever by design :p

> I prefer hidden -> the user needs to explicitely ask for the debug info
> to be shown.
> 
Agreed. But you can tell your app to not provide the debugging info anyway. It 
doesn't force you. Though people'll probably need it ;)

Benjamin