W3C home > Mailing lists > Public > public-webrtc@w3.org > January 2013

Re: RFE: Improve error handling

From: <piranna@gmail.com>
Date: Sat, 5 Jan 2013 17:24:10 +0100
Message-ID: <CAKfGGh3T7hSVuazRkt+_uo4=_gGKD+1AtYh3jw_ffXBGSn4qfQ@mail.gmail.com>
To: cowwoc <cowwoc@bbs.darktech.org>
Cc: public-webrtc <public-webrtc@w3.org>
Showing a possible solution would be dependent of the browser, but giving
more descriptive errors would be done by the specification. Except that, I
agree on all that you have said :-)


2013/1/3 cowwoc <cowwoc@bbs.darktech.org>

> Hi,
>
>     I've been working with WebRTC for 1.5 months now using Chrome and I
> think one of the most frustrating things about the specification is poor
> handling of user errors. The specification needs to be a lot more strict
> with respect to catching user errors and when they occur providing a
> specific explanation of what went wrong. I'll provide one specific example
> which you can extrapolate to the rest of the API.
>
>     I spent a couple of days trying to figure out why
> setRemoteDescription() was returning "SetRemoteDescription failed." It
> returns the same error if the PeerConnection state is wrong (user skipped
> an initialization step), or the description type is wrong ("answer" vs
> "offer") or even if you invoke it one too many times (I had it in a loop by
> mistake).
>
>     Each error case should throw a different message. The message should
> indicate what went wrong and (if possible) how to fix it.
>
>     Another source of frustration are "silent failures" as a side-effect
> of the asynchronous nature of the API. I've repeatedly run into cases where
> I was expecting an event to get fired but it never did. It's one thing for
> the API to return a vague error. It's even worse when it doesn't return an
> error at all and the application hangs.
>
>     For example, I'm adding a remote stream is added to an autoplay
> <video> element (as seen in http://apprtc.appspot.com/) but for some
> reason nothing is happening. It looks like the video isn't being sent by
> the remote peer but the API provides no mechanism for debugging this
> because addStream() provides no events. I'm listening on all PeerConnection
> event listeners and see no obvious problem. I'm fairly certain this is a
> user error because http://apprtc.appspot.com/ runs fine on the same
> computer but my point is these kinds of problems should be easier to
> troubleshoot.
>
>     Thanks for listening :)
>
> Gili
>
>
>


-- 
"Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton
de sitios diferentes, simplemente escribe un sistema operativo Unix."
 Linus Tordvals, creador del sistema operativo Linux
Received on Saturday, 5 January 2013 16:24:58 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:32 UTC