Error handling

[aboba]

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.

[aboba]

This issue has been open for a while. Here is a proposal for resolving it.

1. Add an onerror event to the RTCDTlsTransport object, as follows:

[Constructor(optional RTCIceTransport transport)]
interface RTCDtlsTransport {
attribute RTCIceTransport transport;
readonly attribute RTCDtlsTransportState state;
RTCDtlsParameters getLocalParameters ();
RTCDtlsParameters? getRemoteParameters ();
void start (RTCDtlsParameters remoteParameters);
void stop ();
attribute EventHandler? onstatechange;
attribute EventHandler? onerror;
};

interface onerror : Event {
readonly attribute DOMError e;
};

1. Add an onerror event to the RTCDataChannel interface (this is already supported in WebRTC 1.0).

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;
b. The RTCIceListener and RTCRtpListener objects are simple enough that an onerror event doesn't seem needed;
c. Errors in SCTP transport establishment will presumably surface via the RTCDataChannel.onerror event, so that an onerror event wouldn't be needed for the RTCSctpDataTransport object;
d. The Stats API supports an error callback (although it isn't clear to me when this would fire), and this is probably sufficient.