- From: Mark Watson <watsonm@netflix.com>
- Date: Thu, 6 Mar 2014 17:49:14 -0800
- To: Ryan Sleevi <sleevi@google.com>
- Cc: "public-webcrypto@w3.org" <public-webcrypto@w3.org>
- Message-ID: <CAEnTvdAxezf4zzYLejEBK4EXiT3MmE8A=CwkWLRsPbc-hNAgag@mail.gmail.com>
Hi Ryan, Yes, we can wordsmith this in Last Call. I'll move the return-an-error definition to the Terminology section. It's certainly clear now that the promise gets rejected with a DOMException and not null, which was the decision we wanted to make before Last Call according to our call Monday. We've had a try ... catch model for a long time, but we could certainly change it. The one consideration is that some operations get called from multiple methods - and potentially some from other operations. We would need to decide if it is ever necessary for a caller to catch the error from a callee and do something other then reject the promise with that error ? I don't think we have that now, but will we never have that ? It should be simpler, now, to global-change the "return an error" rather than manually changing all 300+ of them as I just did ... ...Mark On Thu, Mar 6, 2014 at 5:01 PM, Ryan Sleevi <sleevi@google.com> wrote: > > > > On Wed, Mar 5, 2014 at 3:59 PM, Mark Watson <watsonm@netflix.com> wrote: > >> All, >> >> Our SubtleCrypto methods do *not* "throw" errors. Instead we call the >> reject handler of the promise with the error object (to be a DOMException >> according to the other thread). >> >> My question is how we should describe termination with errors in the >> asynchronous substeps and the steps of the operations. We could say: >> >> "Return a SyntaxError" >> >> or >> >> "Throw a SyntaxError" >> >> In either case we need to make the Step 4 or each method clearer: >> >> "4. If the following steps or the steps of invoked operations >> (throw|return) an error, perform the following sub-steps and terminate this >> algorithm" >> >> Since we might invoke other web platform procedures - like WebIDL type >> conversion for example - which "throw" errors - perhaps we should use the >> throw terminology in our procedures (and handle it in Step 4 of the method >> procedures). Step 4 is like the "try ... catch ... " around all the >> operations and other referenced procedures below. >> >> Thoughts ? >> >> ...Mark >> > > So, I'm not exactly sure this is much clearer, nor do I believe the spec > is correct. > > For example, your new language for Step 4 seems to redefine what it means > to "return an error" in some sort of scope, except that scope is not > linguistically clear. > > It's also unclear why "return an error" was placed in Section 14, rather > than in the Terminology section, with all the other spec linguistic > conventions. > > I'm wondering if it's clearer to say that "resolver" is passed to the > operation (eg: Step 9 in verify, Step 8 in digest), and then let the > individual operation use linguistic shorthand, something like > > "When this specification says reject <resolver> with a <name> exception, > the user agent must perform perform the following steps: > 1. Let <resolver> be the promise's associated resolver > 2. Let <code> be zero. > 3. If <name> is in the first column of the error names table and has a > corresponding legacy code exception field value in the third column, set > code to that value. > 4. Run <resolver>'s reject(value) operation, with value as a new > DOMException exception, whose message is a user-agent defined value, name > is <name>, and whose code exception field is <code>." > > Within the top-level definitions for the operations (section 14) > > 1. "If [bad condition], reject <resolver> with a Foo exception and abort > these steps" > 2. "If [other bad condition], reject <resolver> with a Bar exception and > abort these steps" > 3. "Let result be the result of performing the [insert operation] > operation specified by normalizedAlgorithm ..." > 4. "If the "reject resolver with a name exception" algorithms aborted the > operation, then abort these steps" > > That is, I'm not a fan of the "try/catch" > > In the above examples, I drew from the following specifications and the > terminology they utilize: > - > http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html#kill-a-worker > - http://dom.spec.whatwg.org/#exception-domexception > - > https://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html > - http://dev.w3.org/2006/webapi/FileAPI/ > - http://dev.w3.org/html5/spec-preview/dynamic-markup-insertion.html > > > >
Received on Friday, 7 March 2014 01:49:42 UTC