search

WICG / digital-goods

Other
50 stars 28 forks source link

Should getDigitalGoodsService reject, rather than resolving with null, if there is no service? #2

Closed mgiuca closed 4 years ago

mgiuca commented 4 years ago

@rsolomakhin:

IMHO, rejection should be used for errors in exceptional circumstances (e.g., SecurityError when invoked in http:// instead of https:// or from a cross-origin iframe that does not have allow="payment") instead of feature detection.

Typical feature detection works by comparing an object to null or undefined: if (window.MyInterface) { doStuff(); }. It may be awkward to use try-catch in a typical feature detection scenario: try { doStuff(); } catch (error) { oops(); }.

I can go both ways on this. I wonder if there is precedent for feature detection that's async. Normally the API just wouldn't be available. (Note that we made the feature detection async for this API, because it's expensive to query whether it's available on the backend, it isn't just a matter of whether the browser has implemented the feature.)

I could see it as more natural to return null and require the programmer to check for it. Failure to do so results in the same outcome (an exception is thrown) in either case. I've done that for now. Can discuss further on this issue.

phoglenix commented 4 years ago

It seems like it isn't contentious to resolve with null, and it's in the explainer example already, so treating this as resolved.