RSS
 

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

17 Jan

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!).

 

Tags: , , , , ,

Leave a Reply

 

 
  1. Stefan Andersson

    January 17th, 2011 at 2:40 pm

    It seems you and @kangax have both encountered this “by design” principle when filing good, valid reports. Amazing.

     
  2. Phil

    January 17th, 2011 at 8:58 pm

    Hang on. Are you sure that link is correct? I’m getting a 404 when I try to even look at it.

    If your link is correct, what on earth are Microsoft playing at? They are getting hammered in terms of market share and already have an utterly turgid reputation in terms of standards interoperability. Surely they’d want to make sure they take all reasonable steps to produce a competitive product.

     
    • Andy

      January 17th, 2011 at 9:34 pm

      Phil, I’m not sure why the link isn’t working. It appears to only work for me, which is ridiculous because the report is set to “Public – visible to everyone…”.

      I think Microsoft have taken a poor “won’t fix” attitude towards a lot of bugs, as Stefan said, it’s not just me. The worst thing is, I honestly don’t think this would take more than 30 minutes of anyone’s time on the IE team.

       
  3. Pierre

    January 24th, 2012 at 2:19 pm

    Stefan, you’r a genius ! You saved me 15kb of reading !!

    Thank youu! Keep it up :) I heart you !!