- From: Alexey Proskuryakov <ap@webkit.org>
- Date: Sat, 01 Mar 2014 11:53:43 -0800
- To: Ryan Sleevi <sleevi@google.com>
- Cc: Mark Watson <watsonm@netflix.com>, Eric Roman <ericroman@google.com>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>
- Message-id: <8D1680E8-6633-4901-8D69-38173DCC97CC@webkit.org>
28 февр. 2014 г., в 12:26, Ryan Sleevi <sleevi@google.com> написал(а): > 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) Yes, I think that this is reasonable. > 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. My original idea was to raise a SyntaxError, simply to differentiate from NotSupportedError above. I agree that this doesn't seem 100% pure indeed. Looking at DOM4, it appears that we are supposed to file a bug asking for a new exception type (similarly to how Encoding spec added EncodingError). This exception will have a zero code, and a name or our choosing (CryptoError I'd imagine). Filing the DOM4 spec bug for CryptoError may be a good way to find out what the latest thinking on this is (it seems to change all the time, as some very new specs use DOMError, yet DOM4 currently says that DOMError "might be nuked"). Another approach would be to refuse painting this particular bike shed, and use a plain JS Error, not a DOMException. Authors need to be prepared to handle JS Errors in rejections anyway, as WebIDL raises these. > 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 >>> >>> >>> >>> >> >> >> > > > - WBR, Alexey Proskuryakov
Received on Saturday, 1 March 2014 19:54:13 UTC