- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Mon, 13 Oct 2014 16:05:29 +0200
- To: Sam Ruby <rubys@intertwingly.net>
- Cc: whatWG <whatwg@whatwg.org>
On Sun, Oct 12, 2014 at 3:01 PM, Sam Ruby <rubys@intertwingly.net> wrote:
> Can you explain in JavaScript terms what the difference is between return
> failure and terminate?
If you simply terminate new URL("http://test:test/") would no longer
throw. (The reason is that the parse algorithm is overloaded. One
version parses a string and returns a URL. The other parses a string
and modifies a URL in place. The former has a need to return failure,
the latter can simply terminate.)
>> And parse error error would be more
>> like flag a parse error, or append a parse error to a list of parse
>> errors. It depends a bit on whether the parser decides to halt on the
>> first one or not.
>
> I don't see anything in the prose that indicates that halting on the first
> parse error is an option.
It's something I've been meaning to add at some point. Mostly for
conformance checkers I suppose.
>> Did you have a look at the open bugs by the way? There's a chance the
>> parsing algorithm will get rewritten at some point to be a bit more
>> functional and less state driven.
>
> Not yet. I'm still seeing a large set of differences between what I am
> producing and what is in urltestdata.txt and need to track down whether the
> problems are in my implementation, the spec, or in the test results.
>
> Once those three are in sync; I'll try to look at the bigger picture.
Cool. Sounds great.
--
https://annevankesteren.nl/
Received on Monday, 13 October 2014 14:05:58 UTC