- From: Ryan Sleevi <sleevi@google.com>
- Date: Tue, 4 Jun 2013 15:52:04 -0700
- To: "public-webcrypto@w3.org" <public-webcrypto@w3.org>
As mentioned on our call yesterday, I'm curious for input on the expected failure mode for key-based operations https://dvcs.w3.org/hg/webcrypto-api/raw-file/0e4d8673531e/spec/Overview.html For example, generateKey describes the error handling mode as invoking the resolver's reject algorithm, with 'null' as the value. A thought occurred to me as to whether or not we should be generating a DOMError when rejecting - eg: https://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#interface-domerror This would be akin to the FileReader interface (eg: http://dev.w3.org/2006/webapi/FileAPI/#ErrorAndException ), which describes a mapping between particular DOMErrors and states of the FileReader. However, to be clear: I'm NOT trying to advocate the "Let's introduce 100 unique error codes for <insert vendor solution> here". Unless there are compelling answers to the following questions, I consider the reject-with-null to be the most appropriate response. 1) What are the types of errors that can occur when performing Key operations 2) If an error is generated, can the script author take any form of action based upon understanding the nature of the error? eg: Can they alter input parameters such that it succeeds, or is it a "Failure is failure" mode? As much as I'm all in favour of exposing additional data, if the error status cannot result in actionable distinctions, I think it merely complicates the API for now end-user improvement.
Received on Tuesday, 4 June 2013 22:52:31 UTC