This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
SyntaxError: A required parameter was missing or out-of-range DataError: Data provided to an operation does not meet requirements If method parameters are out-of-range this should be a SyntaxError, if something is wrong with octet string data provided to the method then this is a DataError. Specific cases to fix: - validation of extractable in DH import
Additional cases - validation of length fields in various cases
SyntaxError should be a syntax error, no? Out-of-range in Web IDL throws a TypeError. It might be good to just align with that. Alternately you could consider RangeError, and maybe even coordinating that with Web IDL changing its out-of-range handling.
And note that in general parameter validation failures in Web IDL throw TypeErrors.
That may well be a good idea. I'd like to hear what others think. For the moment I'll at least make the specification internally consistent.
https://dvcs.w3.org/hg/webcrypto-api/rev/8bdec08fdc99
Regarding TypeError for out-of-range cases. If the value is actually outside the range that is value for the data type, for example a negative integer provided for an unsigned int type, this makes sense. But if the value is in-range for the type but invalid for some application-specific reason (e.g. key lengths that can only be one of a set of specific values) that seems like a different kind of out-of-range.
(In reply to Mark Watson from comment #4) > That may well be a good idea. I'd like to hear what others think. For the > moment I'll at least make the specification internally consistent. I agree with Boris that SyntaxError surprises me. DataError made some degree of sense, but it had its own set of complexity attached to it. TypeError strikes me as more internally consistent. Or is InvalidAccessError more consistent?
(In reply to Ryan Sleevi from comment #7) > (In reply to Mark Watson from comment #4) > > That may well be a good idea. I'd like to hear what others think. For the > > moment I'll at least make the specification internally consistent. > > I agree with Boris that SyntaxError surprises me. It's not surprising it was used this way given then definition we have (see comment #0), but I think the definition is wrong. Out-of-range is not a 'syntax' issue. In fact I am not sure there can be any syntax problems with a method call other than missing required parameters: everything passed in is already a valid JS type and if it is not the right type this is a TypeError. We could say "missing or invalid" in the SyntaxError definition just in case. > DataError made some degree > of sense, but it had its own set of complexity attached to it. TypeError > strikes me as more internally consistent. > > Or is InvalidAccessError more consistent? We've used InvalidAccessError for cases where you try to use a key for something it cannot do: it doesn't have the right usage or extractable value or providing the wrong kind of public key to a DH derive. Shall we switch to TypeError for the out-of-range cases ? Note that this is dependent on the other discussion of whether we should switch to OperationError to give flexibility to implementations to delegate range checks to libraries that might not expose the reason for a failure.
Agreed at f2f to switch to TypeError for out-of-range cases.
https://dvcs.w3.org/hg/webcrypto-api/rev/b8f161c372a5 There is one common case where SyntaxError is used which I have left as a SyntaxError. This is the case where incorrect usages are supplied. That is, recognized usage values, but incorrect for the type of key being generated, imported or unwrapped. It doesn't seem right to call this a TypeError, since as far as the usages data type is concerned the information is correct. Please re-open if you disagree.