Quantcast
Channel: What the Head Said » Bugs
Viewing all articles
Browse latest Browse all 2

Helpful error messages aren’t just a JavaScript’s throw away

$
0
0

This is one that’s been bugging me for years, but today something happened that finally made me decide to rant about it. ECMAScript’s throw statement has it’s uses in try... catch... finally blocks but it’s also used often outside, on its own, to halt script execution. The most notable example I can think of is on line 480 of Crockford’s json2.js:

// If the text is not JSON parseable, then a SyntaxError is thrown.

            throw new SyntaxError('JSON.parse');

Now, most browsers don’t have a problem with this and not just because they support native JSON.parse. They will happily throw this exception and output the error message appropriately. Except for our old buddy, Internet Explorer. Internet Explorer does something amazingly stupid. It successfully throws an error, but the message accompanying it is “Exception thrown and not caught”. Wow, that’s so ridiculously unhelpful I could cry (but I promised myself I wouldn’t). I’m forced to hunt down the source of the error in my JavaScript code, something that was no easy task in IE 7 due to inaccurate reporting of line numbers and file names. You could argue that “JSON.parse” isn’t a very valuable error message either, but that’s beside the point.

The strange thing is that Internet Explorer will behave properly if the throw statement is throwing an Error object. The error message will be the one supplied to the Error constructor. So why doesn't this happen for Error's brethren; EvalError, TypeError, SyntaxError, RangeError, URIError and ReferenceError? Other browsers will display the error message even if you just throw a string.

When Internet Explorer 9 hit beta, I decided to report this as an "interoperability issue". The Internet Explorer team are always banging on about how they're trying to make Internet Explorer work like other browsers by following standards and non-standard, but popular, implementations of various functionality. I thought to myself, "How hard can it be to fix this?". Surely, there will be one code path for if you throw an Error object and another code path for everything else, so the first one could be quite easily expanded to accommodate everything else instead? As it happens, today my issue was changed to "Resolved", then "Closed" as "By design".

So there you have it, straight from the horse's mouth; Internet Explorer hinders your development in as many ways as possible "by design".

For some reason, the link to the bug report is telling people they don't have the required permissions to view. It is set to public, however, so I'm not sure what's going on there (perhaps they want to hide their shame!).


Viewing all articles
Browse latest Browse all 2

Latest Images

Trending Articles





Latest Images