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

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
>>
>>
>>
>>
>
>
>