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

RFE: Improve error handling

From: cowwoc <cowwoc@bbs.darktech.org>
Date: Thu, 03 Jan 2013 14:25:19 -0500
Message-ID: <50E5DB1F.5050704@bbs.darktech.org>
To: public-webrtc@w3.org

     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 :)

Received on Saturday, 5 January 2013 08:24:45 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:39 UTC