New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error handling #26
Comments
This issue has been open for a while. Here is a proposal for resolving it.
[Constructor(optional RTCIceTransport transport)] interface onerror : Event {
On reviewing the rest of the specification, it wasn't obvious that other modifications were needed. For example: a. The RTCIceTransport object has an ongatherfailure event. This seemed like the most common error, so it wasn't clear that an onerror event was needed in addition; |
- Support for contributing sources removed (re-classified as a 1.2 feature), as described in w3c#27 - Cleanup of DataChannel construction, as described in w3c#60 - Separate proposal on simulcast/layering, as described in w3c#61 - Separate proposal on quality, as described in w3c#62 - Fix for TCP candidate type, as described in w3c#63 - Fix to the fingerprint attribute, as described in w3c#64 - Fix to RTCRtpFeatures, as described in w3c#65 - Support for retrieval of remote certificates, as described in w3c#67 - Support for ICE error handling, described in w3c#68 - Support for Data Channel send rate control, as described in w3c#69 - Support for capabilities and settings, as described in w3c#70 - Removal of duplicate RTCRtpListener functionality, as described in w3c#71 - ICE gathering state added, as described in w3c#72 - Removed ICE role from the ICE transport constructor, as described in w3c#73
From: Adalberto Foresti aforesti@microsoft.com
To: public-orca@w3.org
Subject: error handling
Date: Sun, 26 Jan 2014 21:16:54 +0000
URL: http://lists.w3.org/Archives/Public/public-orca/2014Jan/0037.html
An area where the spec does not delve into much detail yet is the error handling strategy. To make an example among other possible ones:
RTCDtlsTransport does not offer any way to communicate failure to establish transport currently. There is neither a failure callback in the constructor, nor a "failed" state. A possible way to address this is to add such a "Failed" state to the RTCDtlsTransportState enum and use it to notify via onstatechange event.
Thoughts? (on either this specific scenario or the more general issue)
Adalberto Foresti
Principal Program Manager
Microsoft Open Technologies, Inc.
A Subsidiary of Microsoft Corporation
[Justin Uberti]
I think we need the ability to surface details about the error; also, an
error could occur at any time, not just while handshaking (e.g. upon
receipt of a DTLS alert).
So while a 'failed' state may make sense, it may be better to simply have
errors trigger a change to "closed" with an accompanying .onerror callback
that surfaces a detailed error object.
[Martin Thomson]
That makes plenty of sense to me. onerror seems like a general
pattern worth following. Having more direct error reporting for
specific actions can still be useful, but I'd expect that with an
'onerror', the bar would be higher for adding secondary error
reporting channels.
The text was updated successfully, but these errors were encountered: