26903 2014-09-25 17:00:14 +0000 Parameter validation errors should return SyntaxError not DataError 2014-10-30 23:25:06 +0000 1 1 1 Unclassified Web Cryptography Web Cryptography API Document unspecified PC All RESOLVED FIXED P2 normal --- 25741 1 watsonm watsonm bzbarsky public-webcrypto sleevi oldest_to_newest 112179 0 watsonm 2014-09-25 17:00:14 +0000 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 112187 1 watsonm 2014-09-25 17:58:28 +0000 Additional cases - validation of length fields in various cases 112194 2 bzbarsky 2014-09-25 20:21:05 +0000 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. 112195 3 bzbarsky 2014-09-25 20:21:36 +0000 And note that in general parameter validation failures in Web IDL throw TypeErrors. 112200 4 watsonm 2014-09-25 21:48:27 +0000 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. 112226 5 watsonm 2014-09-26 00:44:46 +0000 https://dvcs.w3.org/hg/webcrypto-api/rev/8bdec08fdc99 112276 6 watsonm 2014-09-26 17:39:35 +0000 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. 112777 7 sleevi 2014-10-07 02:58:41 +0000 (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? 112790 8 watsonm 2014-10-07 14:23:07 +0000 (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. 114246 9 watsonm 2014-10-30 16:40:43 +0000 Agreed at f2f to switch to TypeError for out-of-range cases. 114293 10 watsonm 2014-10-30 23:25:06 +0000 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.