Re: Bug 24813 - Decide whether methods should return DOMError or null on failure

I had the same experience: it is rather difficult to use the API as a
developer without some form of error information.

To workaround the "reject with null" requirement, the Chromium
implementation logs the error details to the dev tools console. I have
found this approach to be sufficient.

The errors of most interest to me were incorrect usage of the API (i.e.
some algorithm parameter was missing or malformed, the key was not
extractable, it lacked the required usage, wrong key passed in, key length
was wrong, myriad of JWK errors, etc.).

For these errors being able to distinguish them programatically at runtime
is probably not that useful, since it was an error in how the function was
called (not likely your webapp would respond any differently... unless it
was forwarding inputs directly from the user).

The only errors that I think would be interesting to distinguish
programatically at runtime are unsupported functionality, or algorithmic
failures. However when you rule out incorrect API usages this is mostly
what is left, so after development phase you could probably assume this is
the issue.


On Fri, Feb 28, 2014 at 9:45 AM, Alexey Proskuryakov <ap@webkit.org> wrote:

>
> My personal experience writing regression tests for WebCrypto convinced me
> that it's difficult to use the API without detailed errors being produced
> for mistakes. At least I could resort to stepping through the
> implementation in a debugger, which will not be an option for most.
>
> Note that per <
> https://github.com/domenic/promises-unwrapping/blob/master/docs/writing-specifications-with-promises.md
> >,
>
> ---------------------------------
> Promise rejections should always be instances of the ECMAScript Error
> type, just like synchronously-thrown exceptions should always be instances
> of Error as well.
>
> In particular, for DOM or other web platform specs, this means you should
> never use DOMError, but instead use DOMException, which per WebIDL extends
> Error.
> ---------------------------------
>
> So, the suggestion is to use DOMException, not null. I don't personally
> care which exception codes to use, however a good implementation should
> provide a helpful explanatory message for each rejection.
>
> - WBR, Alexey Proskuryakov
>
> 28 февр. 2014 г., в 8:47, Ryan Sleevi <sleevi@google.com> написал(а):
>
> > Are you making a proposal for what the errors should be?
> >
> > That was and remains what's missing - someone to demonstrate value in
> having discrete errors by making a proposal.
> >
> > On Feb 28, 2014 8:44 AM, "Mark Watson" <watsonm@netflix.com> wrote:
> > https://www.w3.org/Bugs/Public/show_bug.cgi?id=24813
> >
> > Opinions ?
> >
> > ...Mark
>
>
>
>