| 01:05 | <gsnedders> | Hixie: yeah, I know individually the coverage is not great |
| 01:05 | <gsnedders> | Hixie: the sum of both the tokenizer and tree construction is good |
| 01:07 | <gsnedders> | (this is one of the things I want to fix this summer) |
| 01:45 | <Hixie> | gsnedders: k |
| 01:46 | <Hixie> | gsnedders: i was just amused because i've been slowly writing code as each test fails, and then suddenly i was passing all the tokeniser tests, and i had like 15 "XXX" bits in my tokeniser still... |
| 03:33 | <Hixie> | woah |
| 03:33 | <Hixie> |  <!DOCTYPE test>... |
| 03:33 | <Hixie> | i bet old UAs didn't parse that like we do now |
| 03:34 | <Hixie> | i wonder how i can test that |
| 03:34 | <Hixie> | i haven't seen an old browser in years |
| 03:42 | <MikeSmith> | Hixie: I seem to remember thet |
| 03:42 | <MikeSmith> | *there being some thing that let you test in Netscape 4 |
| 03:42 | MikeSmith | looks |
| 03:43 | <Hixie> | dunno how you'd even test that in n4 |
| 03:43 | <MikeSmith> | http://virtuallyfun.superglobalmegacorp.com/?p=3866 |
| 03:45 | <MikeSmith> | server-side thing, I guessーit just generates PNGs you can view |
| 03:45 | <MikeSmith> | anyway |
| 03:47 | <MikeSmith> | Hixie: I don't understand what's so exceptional about how  <!DOCTYPE test> gets parsed |
| 03:47 | <MikeSmith> | looking at the DOM for it I see pretty much what I'd expect |
| 03:49 | <Hixie> | MikeSmith: it's invalid xml, for example. |
| 03:50 | <Hixie> | MikeSmith: no charrefs before the root element |
| 03:50 | <MikeSmith> | ok |
| 03:50 | <MikeSmith> | ah yeah |
| 03:51 | <MikeSmith> | in other news, I'm reading the statement "it is extremely rare in JavaScript to rely on checking a specific exception type" and wondering why that's true |
| 03:51 | <MikeSmith> | I mean I assume that's just stating common practice |
| 03:52 | <MikeSmith> | that is, that web devs don't typically check for specific exceptions, something either just throws or it doesn't |
| 03:52 | <MikeSmith> | I guess |
| 03:52 | <zewt> | well, because javascript as a language sucks at it, presumably |
| 03:53 | <Hixie> | doesn't really suck at that |
| 03:53 | <Hixie> | compared to other languages |
| 03:53 | <Hixie> | does it? |
| 03:53 | <Hixie> | i mean i guess some have special syntax for different handlers for different classes of exceptions |
| 03:53 | <zewt> | https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/try...catch didn't even know about the "var if condition" syntax, is that widely supported? |
| 03:53 | <zewt> | never seen it in code |
| 03:54 | <MikeSmith> | makes me wonder why we go to the trouble of defining specific exceptions if in practice nobody cares, or no code changes any behavior based on what the exception is |
| 03:54 | <zewt> | filtering exception handlers by class is exception handling 101, i've always found it bizarre that javascript has no syntax for it (but maybe the "if" syntax is meant for that) |
| 03:54 | <Hixie> | oh wow |
| 03:54 | <Hixie> | i didn't know about that either |
| 03:54 | <zewt> | trying it |
| 03:55 | <Hixie> | Note: This functionality is not part of the ECMAScript specification. |
| 03:55 | <zewt> | all that matters is whether it's implemented, heh |
| 03:55 | <MikeSmith> | so maybe people don't try to do it because they already know it doesn't work reliably? or the language doesn't provide what's needed for proper exception handling? |
| 03:55 | <zewt> | parse error in firefox |
| 03:55 | <MikeSmith> | s/language/platform |
| 03:56 | <zewt> | maybe because most day-to-day errors come via error events, rather than exceptions? |
| 03:56 | <zewt> | (since most code is still async in the UI thread, not worker stuff) |
| 03:56 | <zewt> | most exception handlers i can think of writing are just "catch all errors to log them to the server, because we don't really except to get any exceptions at all" |
| 03:57 | <zewt> | which is definitely unlike most other languages i work with |
| 03:57 | <MikeSmith> | zewt: I see, ok |
| 03:57 | <MikeSmith> | that makes sense |
| 03:57 | <zewt> | (platforms, rather) |
| 03:57 | MikeSmith | wonders what Domenic_ would say |
| 03:58 | <MikeSmith> | I'm not an idiomatic JavaScript programmer |
| 03:58 | <zewt> | i know i write way more exception handlers in python than JS, in any case |
| 03:58 | <zewt> | and i'd go nuts if python didn't have class filtering |
| 03:59 | <MikeSmith> | well, for sure I write a ton in Java |
| 03:59 | <MikeSmith> | not that I'm proud of it |
| 03:59 | <MikeSmith> | that's just what Java forces on me |
| 03:59 | <zewt> | java shoves them down your throat, heh |
| 03:59 | <zewt> | i tend to make all of my exceptions unchecked in java to avoid that nonsense |
| 04:00 | <MikeSmith> | well for me it works well within the Java universe |
| 04:01 | <MikeSmith> | e.g., the validator code is exception handling stacked on exception handling all over the place |
| 04:01 | <MikeSmith> | but I guess that's the nature of that particular app |
| 04:01 | <MikeSmith> | inherent in it, in that its entire purpose is to report errors of varying kinds |
| 04:02 | <zewt> | i find it's one of the many things that makes java a nightmarish, developer-hostile environment seemingly designed by academics with zero practical experience |
| 04:02 | <zewt> | (re: java is probably my single most hated language) |
| 04:02 | <zewt> | (combination of really terrible language + forced to use it for Android) |
| 04:02 | <MikeSmith> | to me it's more a fact of life I guess |
| 04:03 | <MikeSmith> | I suppose I should question it terribleness more |
| 04:03 | <MikeSmith> | but it's like trying to fix the government or something |
| 04:03 | <zewt> | i picture some college kid just being told by his CS201 prof "all errors should be declared explicitly and you should handle every error deliberately" going on to bake that nonsense into a langauge to force it on everyone else |
| 04:04 | <zewt> | also language |
| 04:04 | <MikeSmith> | oh well yeah |
| 04:04 | <MikeSmith> | it shouldn't set a precedent for anything else, that's for sure |
| 04:04 | <MikeSmith> | though I guess it unfortunately has |
| 04:05 | <zewt> | java should serve as a cautionary tale to other languages, and nothing more |
| 04:05 | <zewt> | heh |
| 04:06 | <MikeSmith> | but getting back to the platform, the vast majority of the failures in the DOM test suite apparently come down to implementations not throwing the exceptions that the spec says they should throw |
| 04:07 | <MikeSmith> | and I can say that holds true for some other parts of the web-platform-tests suite |
| 04:08 | <MikeSmith> | and those wrong-exception-type bugs tend to stick around for a long time without anybody caring enough to fix them |
| 04:08 | <MikeSmith> | I assume that's in part because webdevs don't complain about those bugs and demand they be fixed |
| 04:09 | <MikeSmith> | they're not pain points, in practice |
| 04:09 | <zewt> | i think separate exception types for "programming error"-class exceptions are probably less useful in general |
| 04:09 | <MikeSmith> | aok |
| 04:09 | <MikeSmith> | *ok |
| 04:09 | <zewt> | you don't usually try to catch different classes of programming errors, you just log them and fix the bug... |
| 04:09 | <MikeSmith> | I see |
| 04:10 | <zewt> | and i'm guessing, but DOM exceptions like "you tried to stick a node where it can't go" are probably programming errors? |
| 04:10 | <zewt> | s, s/you/i/ i guess heh |
| 04:11 | <MikeSmith> | I guess they are, yeah |
| 04:12 | <MikeSmith> | but honestly I guess I don't think about that much when I'm reviewing tests or writing them while reading the spec |
| 04:12 | <MikeSmith> | I guess I should |
| 04:12 | <zewt> | having them under a base class like python's RuntimeError might be useful (to distinguish them as programming errors), but finer than that I'm not sure |
| 04:12 | <MikeSmith> | yeah, that |
| 04:13 | <MikeSmith> | of course Java does things that way too, to a degree |
| 04:13 | <zewt> | well, Python's RuntimeError and Java's RuntimeError (RuntimeException? been a while, I forget) are different beasts |
| 04:13 | <MikeSmith> | ah OK |
| 04:14 | <zewt> | python's means (to my interpretation) "programming error", java's means "unchecked error that you don't have to declare in the exception specifier", right? |
| 04:14 | <MikeSmith> | yeah pretty much, as far as Java |
| 04:15 | <zewt> | netsplittin' like it's 1996 |
| 04:16 | <zewt> | oh, irccloud dying |
| 04:16 | <zewt> | amusing that you can tell who uses irccloud even with masked hostnames |
| 04:16 | <zewt> | * timeless (sid4015@firefox/developer/timeless) Quit (Ping timeout: 240 seconds) |
| 10:44 | <jgraham> | Hixie: Specifically it's because those tokenizer states postdate Philip` generating a huge number of tokenizer tests |
| 18:05 | <Domenic_> | the `if` syntax in `catch` is a Mozilla-specific extension. MDN is not very clear on these sorts of things. |
| 18:06 | <Domenic_> | JS developers do rarely filter exception types, but IMO this is because most exceptions they deal with that could be recovered from result from async ops. (E.g., network failures, permission errors, ...) |
| 18:07 | <Domenic_> | I am hopeful that ES will grow better exception-filtering syntax; in the meantime, `promise.catch(e => { if (e.name !== "NetworkError") { throw e; } /* recover from e */ })` will work OK |
| 18:08 | <Domenic_> | or `try { result = await promise; } catch (e) { if (e.name !== "NetworkError") { throw e; } /* recover from e */ }` with await syntax |
| 18:08 | <Domenic_> | Related es-discuss thread http://esdiscuss.org/topic/try-catch-conditional-exceptions-in-light-of-generators |
| 18:08 | <zewt> | that syntax needs to be shot into the sun |
| 18:09 | <Domenic_> | also http://esdiscuss.org/topic/error-objects-in-w3c-apis |
| 18:09 | <Domenic_> | zewt: which syntax? |
| 18:09 | <zewt> | "e => {" |
| 18:10 | <Ms2ger> | I sure am glad we don't shoot everything zewt dislikes into the sun |
| 18:10 | <Domenic_> | lol yes, arrow functions are <3 |
| 18:11 | <zewt> | completely unobvious syntax |
| 19:17 | <odinho> | Throwing the wrong kind of exception is less worse than throwing no exception at all. |
| 19:22 | <jgraham> | Yeah, but it's rather hard to codify the badness of failures in tests. And it's only considered acceptable because people have learnt not to depend on it |
| 19:23 | <jgraham> | If javascript wasn't a bit rubbish, it would be quite important |
| 19:24 | <zewt> | not sure about that; the APIs tend to depend on people catching exceptions much less, too (at least the async versions) |
| 19:24 | <zewt> | (less than APIs in most other platforms) |
| 20:40 | <IZh> | Hi. Why no UNIX timestamp support in datetime fields? It is easier to parse. |
| 21:54 | <foolip> | Hixie: I was mistaken, the parser doesn't set the attributes one by one, it has them all ready and sets them after creating the element. It was after that point I tried adding a hook that showed up in performance tests. |
| 21:56 | <foolip> | maybe there is some trick I could use to make Blink match the spec, but it would be a special-case, since almost everywhere parser-set and script-set attributes are handled in the same code path, which is nice. |
| 21:58 | <foolip> | how hard I try to find that trick depends on how much you hate any of the alternatives that don't have a special case |