Re: addIceCandidate needs an error callback

On Fri, May 3, 2013 at 6:18 AM, Harald Alvestrand <harald@alvestrand.no>wrote:

>  On 05/02/2013 08:59 PM, Eric Rescorla wrote:
>
> The spec says about addIceCandidate()
>
>  An exception with an RTCError object of type INVALID_CANDIDATE_TYPE is
> thrown if candidate parameter is malformed.
>
>  I believe this doesn't match with our agreed error handling principles:
>
>  Say I add a candidate with a bogus candidate string (e.g., a missing
> "typ" field or something).
>
>  Like malformed SDP, this should be handled with an error callback.
>
>  -Ekr
>
>  It would also be consistent with our error handling principles
>

That's not how I understood the principles described at either TPAC or the
Interim. I.e., this is not a programming error, it is a data error, just
like
bogus SDP (which we've already agreed is reported via callback),

Note: I'm not saying that if you pass in a non RTCIceCandidate value
you get a callback. That creates an exception.

[...]


Are there specific reasons why you'd prefer an error callback?
>

Because otherwise we require ICE candidates to be verified on the main
thread.


With that said, I think that the error handling principles *should* be clear
enough to determine this (indeed, I thought they were and came down
on my side.) I.e., I believe they should indicate one right answer.

ISTM that if we draw the line between "programming errors" and
"runtime errors/data errors", then it's clear that this falls into the
latter
category. I.e., you can get bogus candidates (just like bogus SDP)
from some other side which you don't control.

Do you disagree? If not, do you have a different line in mind?

-Ekr