This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Sometimes the spec says: throw a FooError exception and abort these steps and sometimes it just says throw a FooError exception (For example, see 7.6: almost every arm of the 'switch' has both forms.) Are these actually different? Can you throw an exception *without* aborting an algorithm? (And is that what the second form means?) If (I'm guessing) every throw has an implicit "abort these steps", there's still the fact that "abort these steps" doesn't imply that the calling algorithm (if any) is aborted. So what does the calling algorithm do when an exception is thrown? Traditionally, an exception unwinds the call-stack until it's caught, but there doesn't appear to be much catching in the spec. So presumably, if the call-stack started with a call to an API method, it propagates out to the method's caller. But what about throws that don't result from an API call? Anyway, there should perhaps be a few sentences in section 2.1 that would answer these questions.
In theory (and this is not mentioned in the spec), all throwing should only occur in the context of an algorithm being invoked by the JavaScript algorithm for handing [[Call]]. The idea is that we are invoking these definitions when we say "throw" (in the order in which they reference each other): http://www.whatwg.org/specs/web-apps/current-work/#throw http://dom.spec.whatwg.org/#concept-throw http://dev.w3.org/2006/webapi/WebIDL/#dfn-throw http://dev.w3.org/2006/webapi/WebIDL/#es-throwing-exceptions That last, I hope, is defined in terms of the ES spec's throw/catch mechanisms. Again, in theory, there's nothing explicit about all this that is to abort the original algorithm. There's several algorithms that survive returning a value, for instance — they should all explicitly say "return [...] and continue asynchronously" or some such. The same applies to throwing an exception. In conclusion, any time an algorithm just says to throw, and doesn't either say to abort, implicitly abort by virtue of running out of steps, or continue asynchronously, there's an error. I've fixed the problems that I could find. Let me know if you see any others.
Checked in as WHATWG revision r7804. Check-in comment: Be more explicit about aborting steps when throwing an exception. http://html5.org/tools/web-apps-tracker?from=7803&to=7804
Let me know if I missed any.
(In reply to comment #3) > Let me know if I missed any. In 9.3.1 "Importing scripts and libraries", in the definition of the importScripts(urls) method, step 3 says: If any fail, throw a SyntaxError exception. Also, in 11.2.3 "The localStorage attribute", step 1 says: The user agent may throw a SecurityError exception instead of returning a Storage object if the request violates a policy decision ... (In reply to comment #1) > There's several algorithms that survive returning a value, for instance > — they should all explicitly say "return [...] and continue asynchronously" > or some such. The same applies to throwing an exception. Although it looks like there's no case that does throw and then continue (the same algorithm) asynchronously. > In theory (and this is not mentioned in the spec), all throwing should only > occur in the context of an algorithm being invoked by the JavaScript > algorithm for handing [[Call]]. Hm, well, there's: Throw a DataCloneError exception in the internal 'structured cloning' algorithm, which is called by the 'structured clone' algorithm, which is called by the 'traverse the history' algorithm, which is called by the tasks queued by: the 'traverse the history by a delta' algorithm and the 'navigating to a fragment identifier' algorithm, which can be invoked by various user interface actions. There's also: throw an InvalidAccessError exception in the activation behavior of 'a' elements that create hyperlinks, which I gather is invoked when a user clicks a link. (But I can't read the spec that well yet, so it's possible that some logic avoids the path to the throw when the cause is user interface actions.)
> In 9.3.1 "Importing scripts and libraries", > in the definition of the importScripts(urls) method, > step 3 says: > If any fail, throw a SyntaxError exception. > > Also, in 11.2.3 "The localStorage attribute", > step 1 says: > The user agent may throw a SecurityError exception instead of > returning a Storage object if the request violates a policy decision ... Thanks, fixed. > Hm, well, there's: > Throw a DataCloneError exception > in the internal 'structured cloning' algorithm, > which is called by the 'structured clone' algorithm, > which is called by the 'traverse the history' algorithm, > which is called by the tasks queued by: > the 'traverse the history by a delta' algorithm and > the 'navigating to a fragment identifier' algorithm, > which can be invoked by various user interface actions. They can only be invoked once the data has already been successfully cloned once before, though. > There's also: > throw an InvalidAccessError exception > in the activation behavior of 'a' elements that create hyperlinks, > which I gather is invoked when a user clicks a link. Good catch, thanks! Fixed. > (But I can't read the spec that well yet, so it's possible that some logic > avoids the path to the throw when the cause is user interface actions.) You seem to be doing far better than most! Your reports have been most helpful.
Checked in as WHATWG revision r7836. Check-in comment: Fix <area> to match <a> in terms of security checking. Also, some editorial fixes. http://html5.org/tools/web-apps-tracker?from=7835&to=7836
Thanks for the quick response on these.
Note: introduced typo "witout"
you already fixed them, sorry