From: Adalberto Foresti aforesti@microsoft.com
To: public-orca@w3.org
Subject: error handling
Date: Sun, 26 Jan 2014 21:16:54 +0000
URL: https://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.