Re: Proposal: Fire a toneDiscarded event while discarding the invalid DTMF values.

Passing in a bad string of tones seems like a programming error, and we
should throw an exception immediately.


On Wed, Jun 11, 2014 at 5:11 AM, Adam Bergkvist <adam.bergkvist@ericsson.com
> wrote:

> On 2014-06-11 14:05, Kiran Kumar Guduru wrote:
>
>> ------- *Original Message* -------
>>
>> *Sender* : Adam Bergkvist<adam.bergkvist@ericsson.com>
>>
>> *Date* : Jun 11, 2014 20:34 (GMT+09:00)
>>
>> *Title* : Re: Proposal: Fire a toneDiscarded event while discarding the
>>
>> invalid DTMF values.
>>
>> On 2014-06-11 11:58, Harald Alvestrand wrote:
>>  > On 06/11/2014 09:44 AM, Kiran Kumar Guduru wrote:
>>  >> Samsung Enterprise Portal mySingle
>>  >>
>>  >> Hi,
>>  >>
>>  >> It has been discussed to discard the invalid DTMF values while
>>  >> playing, instead of raising an error.
>>  >>
>>  >> Instead of just discarding the invalid values.
>>  >>
>>  >> I would like to propose, to fire a 'toneDiscarded' event when any
>>  >> invalid DTMF value is discarded.
>>  >>
>>  >> This may help the app to track the playout properly.
>>  >>
>>  >> What do you say?
>>  >>
>>  >
>>  > Alternatively, we can fire the tonechange event even if the character
>> is
>>  > unrecognized (move the "fire an event" step to before the "discard"
>> step")
>>  >
>>  > I don't see a reason to complexify the interface more with another
>> event
>>  > type.
>>
>> This error case is pretty good match for the predefined
>> InvalidCharacterError DOMError. So we should just throw when the method
>> is called.
>>
>> "InvalidCharacterError": The string contains invalid characters.
>>
>> No new API surface.
>>
>> [Kiran] It mean that, we have to throw an exception every time we come
>> across the the unrecognized value, but still continue to process the
>> remaining tones in tone buffer. Is my understanding correct?
>>
>> If so, can we do this in synchronus way?
>>
>
> We would inspect the string when insertDTMF() is called and throw right
> away. This approach goes against our plan to ignore unrecognized values,
> but I thought the error name was such a good match that I had to at least
> mention it.
>
> /Adam
>
>
>