Re: [w3c/browser-payment-api] Reject acceptedPromise if converting method data fails (#536)

adrianhopebailie commented on this pull request.



> -              <a>payment method identifiers</a> given <var>identifiers</var>.
-              For each resulting payment handler, if payment method specific
-              capabilities supplied by the payment handler match those provided
-              by <var>data</var>, the payment handler matches.
+              <li>Let <var>data</var> be the result of <a data-cite=
+              "!ECMA-262-2015#sec-json.parse">JSON-parsing</a> the second
+              element in <var>paymentMethod</var> tuple.
+              </li>
+              <li>If required by the specification that defines the
+              <var>identifer</var>, then <a data-cite=
+              "!WEBIDL#dfn-convert-ecmascript-to-idl-value">convert</a>
+              <var>data</var> to an IDL value. Otherwise, <a data-cite=
+              "!WEBIDL#dfn-convert-ecmascript-to-idl-value">convert</a> to
+              <a data-cite="!WEBIDL#idl-object">object</a>.
+              </li>
+              <li>If conversion results in an error, reject

@domenic please, try and understand that the majority of this WG are not experts on browser internals. We're trying our best to contribute nonetheless. Have some patience and read the whole comment. 

I only made a code suggestion because the last time I tried to contribute anything @marcoscaceres refused to read it unless it had code in it.

If you re-read my original comment I asked the following question:

> Is it possible to throw and not reject the promise so that the browser can log the error and continue the next iteration of the loop?
> If so, I propose...

I.e. There is a parsing step happening inside a loop. Can the parsing step throw and can the logic inside the loop catch and log the error and then continue?

This is the experience I'd expect a developer to get:
 * They call the API with a list of 3 payment methods
 * They have 3 different payment handlers registered that can each handle one of these payment methods
 * One payment method has bad data
 * They are presented with only 2 payment handlers to choose to handle the payment
 * An error is logged to the browser console

I used the phrase "discard" because in the process of looping through this list of payment methods we are also establishing a list of payment handlers that match them. If a payment method has bad data then it is "discarded" from the set used for matching.

Sorry if that terminology is confusing, I hope you understand my intent now and can suggest a better text replacement?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/browser-payment-api/pull/536#discussion_r123539378