Re: WebCrypto Spec Error Types feedback from MS

So, we have:

NotSupportedError
SyntaxError
InvalidStateError
InvalidAccessError

from DOM4. We need new errors for "unknown error" and "data error".

Is there any reason we should not use the WebIDL predefined exception (
http://heycam.github.io/webidl/#dfn-predefined-exception) Error for the
"unknown error" case ?

Should we generalize "data error" to include any cases where the operation
itself encounters a fatal error ? E.g. OperationError (which would be a new
DOMException defined in our specification.)

WebIDL says that the correct way to throw an exception is like this:

"Throw a DOMException with
name<http://heycam.github.io/webidl/#dfn-exception-name>
HierarchyRequestError
and message <http://heycam.github.io/webidl/#dfn-exception-message> "Cannot
append that Node here".

We want to return the error, not throw. But the above seems a bit of a
mouthful to distribute throughout our specification. IndexedDB, for
example, doesn't bother with this level of detail. If we want to be more
rigorous, though, we could define terminology:

"When this specification says to return an OperationError the user agent
must return a DOMException with name OperationError and message "...".

or

"When this specification says to return a NotSupportedError, SyntaxError,
InvalidStateError, ... or OperationError the user agent shall return a
DOMException with name NotSupportedError, SyntaxError, InvalidStateError,
... or OperationError respectively and message as shown in the following
table ..."

I think this gives us a solid basis to go to Last Call and we can easily
hone the precise errors later.

[Btw, SyntaxError is defined as a DOMException in DOM4, but WebIDL says
that there is a predefined exception of the same name and that new
exceptions must not have identifiers that are the same as the predefined
ones. Anyone know how/if this is going to be resolved ?]

...Mark









On Wed, Mar 5, 2014 at 8:09 AM, Mark Watson <watsonm@netflix.com> wrote:

>
>
>
> On Tue, Mar 4, 2014 at 6:32 PM, Ryan Sleevi <sleevi@google.com> wrote:
>
>>
>>
>>
>> On Tue, Mar 4, 2014 at 6:23 PM, Israel Hilerio <israelh@microsoft.com>wrote:
>>
>>>  As promised, below is MS feedback on the types of error we believe are
>>> useful to expose to web developers.  We correlated this information with
>>> what was done on IndexedDB.  In addition, we when through Section 14.3 and
>>> mapped our proposed error types to steps on each section:
>>>
>>>
>>>
>>> Error Type
>>>
>>> Description
>>>
>>> Spec Mapping
>>>
>>> NOT_SUPPORTED_ERR
>>>
>>> The Algorithm is not supported
>>>
>>> 14.3.1 through 8, 11:
>>>
>>> * Step 6
>>>
>>> 14.3.7:
>>>
>>> * Step 7
>>>
>>> 14.3.9:
>>>
>>> * Step 5
>>>
>>> 14.3.12:
>>>
>>> * Step 6
>>>
>>> * Step 7
>>>
>>> SYNTAX_ERR
>>>
>>> Missing parameter errors.  For example, you fail to provide an IV for
>>> CBC Mode or not providing a key length when one is needed.
>>>
>>> 14.3.1 through 12:
>>>
>>> * Steps 1 and 5
>>>
>>>
>>>
>>> INVALID_STATE_ERR
>>>
>>> An invalid operation was performed on an object instance. For example,
>>> you have exceeded the number of operations allowed with a key.
>>>
>>> 14.3.1 through 4, 8, 11:
>>>
>>> * Step 8
>>>
>>> 14.3.7:
>>>
>>> * Step 12
>>>
>>> 14.3.10:
>>>
>>> * Step 6
>>>
>>>
>>>
>>> DATA_ERR
>>>
>>> Data provided to an operation does not meet requirements. For example,
>>> your plain text is not padded to the correct size.
>>>
>>> 14.3.1 through 5:
>>>
>>> * Step 8
>>>
>>> 14.3.6:
>>>
>>> * Step 7
>>>
>>> 14.3.7:
>>>
>>> * Step 9
>>>
>>> 14.3.9:
>>>
>>> * Step 6
>>>
>>> * Step 7
>>>
>>> * Step 8
>>>
>>> 14.3.10:
>>>
>>> * Step 5
>>>
>>> 14.3.11:
>>>
>>> * Step 7
>>>
>>> 14.3.12:
>>>
>>> * Step 9
>>>
>>> * Step 10
>>>
>>> * Step 11
>>>
>>> * Step 13
>>>
>>> UNKNOWN_ERR
>>>
>>> This is a system level transient failure that don't necessarily indicate
>>> a failure in the program logic. For example, out of memory conditions.
>>>
>>> This could happen in any step
>>>
>>> INVALID_ACCESS_ERR
>>>
>>> An invalid operation was perform in an object type.  For example, you
>>> try to encrypt with a signing key.
>>>
>>> 14.3.1 through 4, 8, 9:
>>>
>>> * Step 7
>>>
>>> 14.3.7:
>>>
>>> * Step 8
>>>
>>> 14.3.11:
>>>
>>> * Step 8
>>>
>>> * Step 12
>>>
>>> 14.3.12:
>>>
>>> * Step 8
>>>
>>>
>>>
>>> Remember you'll need to update step 4 on each 14.3.x to return DOMError
>>> and remove editorial note.
>>>
>>>
>>>
>>> We were also wondering if the following steps should be in the spec
>>> (they seemed redundant):
>>>
>>> ·        Section 14.3.11 Step 13
>>>
>>> ·        Section 14.3.12 Step 12
>>>
>>> ·        Section 14.3.12 Step 14
>>>
>>>
>>>
>>> Let us know if you have any questions.
>>>
>>> Thanks,
>>>
>>>
>>>
>>> Israel
>>>
>>
>> Regarding UNKNOWN_ERR and DATA_ERR, doesn't that require taking a
>> normative dependency on IndexedDB, which defines UnknownError and
>> DataError? I do agree it's useful, I'm just not sure how to handle this. Do
>> we equally define an UnknownError? Is such a thing even possible?
>>
>> Regarding the redundant sections, I agree, they seem redundant, because
>> it seems to be covered by Section 14.3.11 Step 4 ("If an error occurs, run
>> these substeps and then terminate the algorithm")
>>
>> That said, we probably need to smith the language, since really it seems
>> like Step 4 will never be hit (except perhaps in Step 5?) For example,
>> Steps 6, 7, 8, 9, 11, and 12 all separately say "Terminate this algorithm
>> with an error" - which presumably means _don't_ run Step 4.
>>
>> Spec bug!
>>
>
> How about, in Step 4, we say 'If the steps below say "return an error",
> execute the following substeps and terminate the algorithm'.
>
> and then in the remaining steps we say "return an xxx error" instead of
> "terminate this algorithm with an error".
>
> ...Mark
>
>
>
>