Re: Error event/callback for speech synthesis

I think adding an onerror event is the best option because of: clarity of
what it means (as opposed to re-purposing onend) and because it's easy for
an author to assign both onerror and onend to the same function if he
desires (and to use event.type to distinguish). Therefore I propose the
following definition. If there's no disagreement, I will add this to the
spec on Friday.

    interface SpeechSynthesisUtterance {
      ...
      attribute Function onerror;
    };

error event
  Fired if there was an error that prevented successful speaking of this
utterance. If this event fires, the onend event MUST not be fired for this
utterance.


/Glen Shires

On Tue, Oct 9, 2012 at 9:10 AM, Dominic Mazzoni <dmazzoni@google.com> wrote:

> There's one case that isn't covered in the speech synthesis spec: what
> happens if there's an error with a particular utterance that isn't detected
> at the time when it's enqueued?
>
> As an example, suppose the author writes malformed SSML, but the speech is
> implemented in a remote server so the fact that there was an error isn't
> discovered until after several utterances have been enqueued?
>
> Possible solutions:
> * Yet another callback, onerror - that indicates that a particular
> utterance was not and will not be spoken, because there was an error
> processing that particular utterance. Other utterances are unaffected; if
> there was another one in the queue after it, it will start speaking next
> (or error as well).
> * An extra argument in SpeechSynthesisEvent when an 'end' event is fired,
> indicating success or failure, along with an error message. The downside is
> that these arguments wouldn't apply to all callbacks, but the upside is
> that clients could only listen to onend and be sure to get a callback for
> every utterance, rather than needing to listen to onend and onerror.
> * Or, a compromise could be that when there's an error, both onerror and
> onend get fired, in that order - to make things easier for clients.
>
> I think it'd be too limiting to expect that errors could be caught
> synchronously before the call to speak() returns. Web APIs are moving in
> the direction of being more asynchronous, and when speech is likely to be
> implemented remotely, or even locally in a different thread or process, we
> should let speak() return immediately and have an error callback later.
>
> - Dominic
>
>