Re: PROPOSAL: New signature for getUserMedia and callbacks

On Mar 30, 2012, at 7:25 AM, Rich Tibbett wrote:
> In this design a developer MUST to check the value of 'err' so it's not optional as suggested. More on this below...
> 
> Secondly, stack traces occur when exceptions are thrown. Returning an 'err' object in an async callback, regardless of where that is returned, isn't the same as throwing a JavaScript exception. Exceptions are never thrown in this design so we aren't dealing with stack traces.

This brings up another important point that we should discuss (probably in another thread), but I was assuming that if the developer doesn't check the value of err and goes ahead and uses stream anyway, an exception will be thrown:

navigator.getUserMedia(options, function(err, stream) {
  // I don't check err but stream is undefined!
  video.src = stream;
  // Exception thrown?
});

> Putting the error object on a web developer's critical path is unnecessary as it actually forces a developer to add boilerplate error/success type checking:
> 
> navigator.getUserMedia(options, function(err, stream) {
>  // We now MUST check the output before usage since
>  // we cannot be sure at this point if we have an
>  // error or a stream without the following boilerplate
> 
>  if(err) {
>    /* process error */
>  } else {
>    /* process stream */
>  }
> });

Yes, there will be boilerplate. However consider that this is the same as in C, where most lines look like this:

int err = do_something();
if (err) { fprintf(stderr, "oops"); exit(err); }

It isn't great, but that's how good programs *must* be written given the constraints of the language you are dealing with. I don't think it's any different for JavaScript.

> Meanwhile the current proposal removes the need for this boilerplate at all if the developer only wants to react when a stream object is actually provided:
> 
> navigator.getUserMedia(options, function(stream) {
>  /* process stream */
> } /* just don't process errors. what's the harm? */);
> 
> The main question then is why a developer shouldn't just be able to ignore a permission denied error if they so wish? Is there any reason that a developer MUST handle this error callback in their web applications?

Yes, because things will fail, and a developer not checking the result code leads to badly written web applications and a poor user experience. JavaScript gives us a lot of leeway but I think in this particular case we should guide the developer away from shooting themselves in the foot.

I would note that the (err, success) callback paradigm has been wildly successful thanks to node.js, and I think majority of web developers will prefer this over two callbacks, one of which is optional.

-Anant

Received on Monday, 2 April 2012 18:39:25 UTC