This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
From http://lists.w3.org/Archives/Public/public-webcrypto/2014Jul/0024.html * I'm not sure why we're returning Error instances from the "normalize an algorithm" steps instead of just throwing them as exceptions. The latter will do the right thing because WebIDL will convert them to rejected promises, and seems a lot less confusing.
Well, mostly because we never defined in the spec terminology how to handle thrown exceptions from sub-algorithms, hence the ad-hoc handling. Even within the space of "Web" specifications, there are all sorts of different conventions, hence my attempt to just find one and try to stick to it. - DOM - Doesn't provide a generic means of sub-algorithm throwing, e.g. http://dom.spec.whatwg.org/#interface-parentnode - ES6 - Uses ReturnIfAbrupt (and friends) to avoid throwing directly in sub-algorithms, though the net-effect is the same - Web IDL - Describes how to construct Exception objects, but doesn't define propagation rules for subalgorithms. - HTML - Uses terms like "if [sub-step] fails, throw [Exception] and abort the [name of overall algorithm]" I vaguely recall seeing one spec that set out in terminology that exceptions in algorithms specified in the spec (including sub-algorithms) propagate as the results of the operation, unless handled, but for the life of me, I can't find it. I agree, it's useful to get good terminology here, but I'd love to make sure we're uniformly consistent and that we're consistent with other specs.
In the absence of a proposal here, I suggest we close as won't fix.
What exactly would constitute "a proposal"? I thought comment 0 was pretty clear. The HTML and DOM specs both have "throw a ...." language that works well enough for throwing things.
(In reply to Boris Zbarsky from comment #3) > What exactly would constitute "a proposal"? I thought comment 0 was pretty > clear. > > The HTML and DOM specs both have "throw a ...." language that works well > enough for throwing things. When I look at https://dom.spec.whatwg.org/#concept-throw it defines "throw a <string>" in terms of "throw an <object>", but that seems to be all. I understood comment 1 to be questioning whether 'throw an <object>' was well-defined when invoked from sub-algorithms. If it is not well-defined, we need a proposal. The DOM specification seems to explicitly say 'Rethrow any exceptions' when sub-procedures which might throw are invoked. Do we need to do something like that. If you're saying that the propagation of exceptions is well-defined (and Ryan refers to seeing some text to this effect), then I guess we're good to do a global change to the DOMO-like 'throw a <string>' language.
> I understood comment 1 to be questioning whether 'throw an <object>' was > well-defined when invoked from sub-algorithms. I see. A bunch of things regarding exceptions are fairly fuzzy. But the only sane interpretation of "throw" is that you terminate execution of the algorithm and all ancestor algorithms until you get to one that says it catches exceptions. There are complications involved when calling back into JS if _that_ throws an exception; that's what the rethrowing bits in DOM are about, because the call back into JS effectively catches exceptions that JS throws. But you're not in that situation here.
And for what it's worth, I agree that the exact exception propagation rules should be spelled out more clearly somewhere; this is a known pain point in the interaction of the ES, Web IDL, and web platform specs. Everyone pretty much agrees on what the right behavior is, but the combination of specs doesn't quite define it.
Ok, so what I propose is: - we adopt the DOM language 'throw a <string>' - we include (in our spec), and link to, the same definition of this phrase as used in DOM - we enhance that definition with a sentence explaining the only sane interpretation of throw:'terminate execution of the algorithm and all ancestor algorithms until you get to one that says it catches exceptions'. Comments, objections, agreement ?
(In reply to Mark Watson from comment #7) > Ok, so what I propose is: > - we adopt the DOM language 'throw a <string>' > - we include (in our spec), and link to, the same definition of this phrase > as used in DOM > - we enhance that definition with a sentence explaining the only sane > interpretation of throw:'terminate execution of the algorithm and all > ancestor algorithms until you get to one that says it catches exceptions'. > > Comments, objections, agreement ? Works for me
https://dvcs.w3.org/hg/webcrypto-api/rev/4c8aa1eee8c8