Open reillyeon opened 7 years ago
@jyasskin can you give me some advice on whether this is worth doing for the ergonomics of reporting an error for invalid inputs or if the additional constraints will unnecessarily limit us in extending the API later?
Assuming you make this change, I'd guess that if you later want to stop throwing an error for certain inputs that you currently throw an error for, that'll be web-compatible, in a similar way to how adding a method to an object tends to be web-compatible.
I forget what we did in Web Bluetooth for impossible filters: we either just return NotFoundError with an informative message or return a TypeError, and both APIs should probably do the same thing. If we decide that Web Bluetooth should do the opposite of whatever it's currently doing, it's probably web-compatible to change it.
Define an invalid filter as one that contains fields that will not be matched according to the algorithm. For example,
productId
without avendorId
. Throw a TypeError if these are passed to requestDevice().