- From: Ian Hickson <ian@hixie.ch>
- Date: Tue, 17 Sep 2013 18:31:58 +0000 (UTC)
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: WHATWG <whatwg@whatwg.org>, Rik Cabanier <cabanier@gmail.com>, Robert O'Callahan <robert@ocallahan.org>
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. 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. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 17 September 2013 18:33:33 UTC