- From: Rik Cabanier <cabanier@gmail.com>
- Date: Tue, 17 Sep 2013 12:55:06 -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 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. > > It wouldn't be so bad if we had a way to have errors that allowed the code > to continue anyway, the way we do e.g. in HTML parsing, where you can > easily run a validator to find out what you've done wrong, while still > having the errors swept under the carpet on the user's end. The browser could log something in the console output so the developer can debug it. Maybe the spec could say that the operation is in error but that processing will continue as if the bad call didn't happen.
Received on Tuesday, 17 September 2013 19:55:32 UTC