Re: Dropping SDP-specific errors

In fact, we do one better right now (in both spec and implementation): 
SDP errors in Set{Local,Remote}Description cause the returned promise to 
be rejected with an InvalidSessionDescriptionError. In Firefox, we set 
the message field of this error to include details regarding the SDP 
failure, including (if memory serves) line numbers.

/a

On 1/28/16 15:49, Martin Thomson wrote:
> We don't need it.  We can dump stuff into the console if necessary.
> Otherwise, it's hard to see how this is information an app would use
> in normal processing.
>
> On 29 January 2016 at 01:31, Dominique Hazael-Massieux <dom@w3.org> wrote:
>> Hi,
>>
>> The spec has had for ever a description of an RTCSdpError interface:
>> http://w3c.github.io/webrtc-pc/#rtcsdperror
>>
>> The intent of that error (when it was added in 2012) was to have the ability
>> to report in a specific attribute the line number at which a potential error
>> in the SDP blob had been detected by the browser when trying to apply it
>> with setLocalDescription and setRemoteDescription.
>>
>> While that error has been defined, it was never referenced from anywhere in
>> the spec (in particular, not from setLD nor setRD), and as far as I can
>> tell, is not provided by any browser.
>>
>>  From what I understand, their lack of availability hasn't been high on
>> anyone's complaint lists, and it is in general dubious what one could do
>> programmatically once provided with the SDP line number.
>>
>> We also know based on our experience in getUserMedia that defining errors
>> with special attributes is non trivial to specify, and I understand from
>> some implementors that they're not trivial to integrate.
>>
>> I have thus taken the approach of getting rid of RTCSdpError in my pull
>> requests that overhaul the error management of the spec
>>    https://github.com/w3c/webrtc-pc/pull/468
>>    https://github.com/w3c/webrtc-pc/pull/472 in particular
>> https://github.com/w3c/webrtc-pc/commit/154ea0b6cb5d475cdd591a92212f518484b1d853
>>
>> I'm seeking feedback on whether that's an acceptable approach.
>>
>> Dom
>>


-- 
Adam Roach
Principal Platform Engineer
Office of the CTO