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

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