Re: A proposal for renaming MediaStreamError

On 05/09/2014 07:33 AM, Kiran Kumar Guduru wrote:
> Samsung Enterprise Portal mySingle
>
>  
>
> Hi,
>
> MediaStreamError is fired, whenever an error occured on a
> MediaStreamTrack, like
>
> overConstrainedError, constraintNotSatisfiedError, NotSupportedError,
> PermissionDeniedError,
>
> In case of overConstrained,
>
> "This error event fires asynchronously for each affected track "
>
>  
>
> So it seems, better to rename MediaStreamError to MediaStreamTrack
> error, by adding one more attribute representing MediaStream.
>
> interface MediaStreamTrackError {
>
> DomString name;
>
> DomString message;
>
> DomString constraintName;
>
> MediaStream stream;
>
> }
>

I don't really want to do this. The main reason why MediaStreamError
exists is that we were told it was unwise to inherit from DOMError (the
previous "standard error"), so we had to define our own, and the chief
reason why it's not called MediaError is that that name is already in
use in HTML5.

I have doubts about having the (optional) constraint name in there in
the genral case, since it's only useful in the case of errors that have
something to do with constraints - and there are other error cases to
consider - but was convinced that it was easier to do it this way than
to define a new class MediaStreamConstraintError for the extension with
the constraintName.

If you have an use case that requires a stream to be passed back, I
think it would be better to subclass MediaStreamError for that case than
to add more error fields to it in all cases. But this may be a matter of
(dis)taste.


>  
>
> If we are able to find any case specific to MediaStream as a whole is
> needed in any case, before last call, then add a new MediaStreamError
> along with MediaStreamTrackError.
>
>  
>
> Kiran.
>
>  
>


-- 
Surveillance is pervasive. Go Dark.