- From: Rik Cabanier <cabanier@gmail.com>
- Date: Tue, 17 Sep 2013 14:32:03 -0700
- To: Ian Hickson <ian@hixie.ch>
- Cc: WHATWG <whatwg@whatwg.org>, "Tab Atkins Jr." <jackalmage@gmail.com>, Robert O'Callahan <robert@ocallahan.org>
On Tue, Sep 17, 2013 at 1:27 PM, Ian Hickson <ian@hixie.ch> wrote: > On Tue, 17 Sep 2013, Rik Cabanier wrote: > > On Tue, Sep 17, 2013 at 11:31 AM, Ian Hickson <ian@hixie.ch> wrote: > > > On Tue, 17 Sep 2013, Tab Atkins Jr. wrote: > > > > > > > > > > I'm not a fan of "sweep it under the carpet" bug handling, > > > > > personally. It drives me crazy that JavaScript has no type > > > > > checking, no argument checking, etc. So many bugs that should be > > > > > caught at compile time, or at least at runtime when the code is > > > > > reached, are instead caught only after careful testing. > > > > > > > > "Runtime when the code is reached" often actually means "Whoops! Now > > > > the entire app's broken because I forgot to handle a silly > > > > edge-case.". When there's an easy and obvious recovery strategy, > > > > it's often much friendlier to authors to take it rather than force > > > > them to handle errors. > > > > > > Usually in these cases the entire app is probably still broken -- > > > maybe with data corruption, even, or with confusingly bad behaviour. > > > The only difference is that you have no idea where to begin looking. > > > > Ok, so what if *some* applications would be horribly broken. *Others* > > will still stumble along or work perfectly fine. I'd rather have that, > > than a completely broken page. > > Dramatically simplifying the situation here, we're saying that the > available options are: > > A: All buggy applications fail to compile, because of static checking. > Cost to fix the bugs is low. > > B: All buggy applications break entirely when edge cases are hit. > Cost to fix the bugs is moderate. > > C: Some buggy applications break entirely when edge cases are hit. > Some buggy applications have data corruption! > Some buggy applications have merely graphical artefacts. > Cost to fix the bugs is high. > > I think option A is vastly superior, but since that's not an option, > option B is preferable to option C. > You are speaking as a developer, not as a user of a web application. Browser could offer a 'debug' more where they break on bad calls or output messages to the console. Once it's 'released', the runtime should be permissive. > > In reality, I don't think it's true that the Web always goes with C. If it > did, there'd never be exceptions thrown by APIs, and exceptions are thrown > all the time by APIs. Indeed, if it were the case that we had a philosophy > of going with "muddling along" where possible, JavaScript wouldn't have > syntax errors, or, much like CSS, it would have rules for recovering from > them and would simply ignore syntactically invalid constructs. We don't do > that. Instead, we chose the middle ground B most of the time. > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' >
Received on Tuesday, 17 September 2013 21:32:29 UTC