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

When you say "obvious not supported in this implementation", I want to
confirm that you are considering cases both where the algorithm itself (eg:
by algorithm name) is not supported, as well as when the parameters are
outside a range that an implementation supports (eg: odd RSA modulus, hash
alg with an RSA-OAEP/PSS alg, etc)

What's your take on when talking to a library that may defer to the
underlying platform/OS, and the platform/OS doesn't provide clear signal of
failure? It's not always clear that NOT_SUPPORTED_ERR may be right. Is
INVALID_ACCESS_ERR better here? Or ABORT_ERR?

What about internal library failures? INVALID_STATE_ERR seems "close", but
not clear.


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

>
> How about this:
>
> 1. For WebIDL exceptions that we convert to rejections, just use the
> original exception.
> 2. For obvious "not supported in this implementation" cases,
> use NOT_SUPPORTED_ERR.
> 3. For everything else, use SYNTAX_ERR.
>
> - WBR, Alexey Proskuryakov
>
> 28 февр. 2014 г., в 10:54, Mark Watson <watsonm@netflix.com> написал(а):
>
> For this to happen, someone needs to make a concrete proposal as to which
> error codes we should return when, presumably drawing on the list here:
> http://www.w3.org/TR/dom/#exception-domexception
>
> ...Mark
>
>
> On Fri, Feb 28, 2014 at 10:44 AM, Alexey Proskuryakov <ap@webkit.org>wrote:
>
>>
>> Historically, web developers have expressed a lot of interest in getting
>> error information in a form that they could automatically send back to
>> their servers for investigation. Hence window.onerror, and many requests to
>> include JS stack trace in exceptions, not just to show it in local
>> debugging tools.
>>
>> Based on this past experience, I think that exposing the errors in
>> DOMException is superior to simply logging them to developer console. For
>> cases that you enumerated where we expect that programmatic handling is
>> feasible, we could use distinctive codes (like NOT_SUPPORTED_ERR), and we
>> definitely need to always use descriptive messages.
>>
>> Another way to think of this is that async rejections aren't any
>> different from old school exceptions, just delivered differently. If
>> WebCrypto had a sync API, would we raise a DOMException, or raise a null
>> exception, and log details to console? I think that we'd obviously do the
>> former. So, I don't see any reason to reinvent the wheel for promise
>> rejections.
>>
>> If there is a strong reason to use null, we should probably communicate
>> it to TC39, so that <
>> https://github.com/domenic/promises-unwrapping/blob/master/docs/writing-specifications-with-promises.md>
>> could be updated with it in mind.
>>
>> - WBR, Alexey Proskuryakov
>>
>> 28 февр. 2014 г., в 10:20, Eric Roman <ericroman@google.com> написал(а):
>>
>> 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
>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>