Re: Encoding API exceptions

I'd be willing to experiment with changing the exception types in Chromium.
History tells us this sort of change is usually web-compatible, and the
feature still has pretty low usage numbers at this point.

It'd be nice to have more confidence about starting to use RangeError in
web platform features; IIRC an early iteration of the Encoding API design
did use RangeError but we moved away from it! Is there a new spec/feature
that can test the waters first?

On Sun, Nov 9, 2014 at 1:45 AM, Anne van Kesteren <annevk@annevk.nl> wrote:

> Both Chromium and Gecko implement the API. There's interest in this
> API from the wider JavaScript community. Unfortunately for them we use
> a DOMException which so far is the only dependency on "DOM things".
>
> We also use a TypeError based on IDL enumerations, but reportedly IDL
> should attempt switching to RangeError there as that is what
> JavaScript itself uses in such situations. (We cannot use IDL
> enumerations in the Encoding API because we also trim whitespace and
> use ASCII case-insensitve matching.)
>
> I was wondering if there would be interest in changing both Chromium
> and Gecko to throw TypeError where we now throw EncodingError, and
> throw RangeError where we now throw TypeError. My hope is that this
> would make the API more attractive as JavaScript's Encoding API (to
> the extent it isn't that already).
>
> The Encoding API: https://encoding.spec.whatwg.org/#api
>
>
> --
> https://annevankesteren.nl/
>