4

If I write 

try { null = foobar } catch(e) { alert( e ) };

nothing is alerted, but a ReferenceError is logged in the console. However,

try { barfoo = foobar } catch(e) { alert( e ) };

shows an alert with a ReferenceError.

So the question is: what types of errors in what context get caught by try-catch statements?

PurkkaKoodari
  • 6,703
  • 6
  • 37
  • 58
Vlas Bashynskyi
  • 1,886
  • 2
  • 16
  • 25
  • 1
    One helpful illustration of early errors (i.e., parse-time errors) and runtime errors: add a leading `alert(1);` to your `try` block (i.e. `try { alert(1); ... }`). You'll see that it only runs in the second case. In the first case, no alert is produced, because the code never runs (because parsing fails). The `catch` block can't run if *none* of the code ever runs due to a parse error. – apsillers Jul 02 '14 at 09:51

1 Answers1

4

So, your first line of code is invalid JavaScript syntax. That's why you're getting a:
ReferenceError: Invalid left-hand side in assignment (You can't assign vars to null)

Your second line is valid syntax, but throws a:
ReferenceError: foobar is not defined.

Now, the reason the second line does get caught, but the first one doesn't, is because the JavaScript interpreter is throwing the first error when interpreting the code, compared to when it's actually executing it, in the second example.

A more simple explanation, courtesy of @Matt:

It's simply invalid JavaScript syntax vs runtime errors. The latter get caught, the former doesn't.

You can sort of thinking it as the JavaScript interpreter looking at all the code before it executes it and thinking does that all parse correctly? If it doesn't, it throws an uncatchable Error (be it a SyntaxError or ReferenceError). Otherwise, the code beings to execute, and at one point you enter the try/catch block during execution and any runtime errors thrown whilst in there are caught.

Community
  • 1
  • 1
Cerbrus
  • 70,800
  • 18
  • 132
  • 147
  • (Ugh, how do I word this properly...) – Cerbrus Jul 02 '14 at 08:44
  • Is there any way I could handle the first one? – Vlas Bashynskyi Jul 02 '14 at 08:44
  • 1
    Not that I know of. The first should be caught by a proper IDE, though, since it's invalid JavaScript syntax. – Cerbrus Jul 02 '14 at 08:44
  • 1
    Ah, runtime errors, that's what I was looking for! Mind if I quote you in my answer? – Cerbrus Jul 02 '14 at 08:49
  • @Matt: But a reference error is not a syntax error. I looked at the spec but I can't figure out why the first statement wouldn't be caught. I mean, I agree that this could be statically analyzed, but I think it is not. – Felix Kling Jul 02 '14 at 08:52
  • @FelixKling: It makes sense for this syntax error to be classified as reference error, though, since it's an invalid reference. – Cerbrus Jul 02 '14 at 08:55
  • 1
    Mmmh, seems indeed to be what's happening. Code before the assignment isn't executed either. It's still rather confusing. I would have expected that the error is thrown in http://www.ecma-international.org/ecma-262/5.1/#sec-8.7.2. – Felix Kling Jul 02 '14 at 08:56
  • @FelixKling: Easiest example is wrapping it in a function which isn't called; http://jsfiddle.net/6QkpC/. The exception is still thrown. Like you though, I can't find this behaviour explained in the spec. Closest I've got is http://es5.github.io/#x11.13.1 – Matt Jul 02 '14 at 08:58
  • 1
    @Matt: I guess it's better explained in the [ES6 spec](http://people.mozilla.org/~jorendorff/es6-draft.html#sec-assignment-operators-static-semantics-early-errors): *"Static Semantics: Early Errors [...] - It is an early Reference Error if LeftHandSideExpression is neither an ObjectLiteral nor an ArrayLiteral and IsValidSimpleAssignmentTarget of LeftHandSideExpression is false."* And regarding `IsValidSimpleAssignmentTarget`: http://people.mozilla.org/~jorendorff/es6-draft.html#sec-semantics-static-semantics-isvalidsimpleassignmenttarget – Felix Kling Jul 02 '14 at 09:00
  • @FelixKling: Good find. Still unclear as to what browsers were doing/ what advise they were following prior to ES6 though. – Matt Jul 02 '14 at 09:05
  • @Matt: Right. Might be that this is one of the things that browsers were always doing and now it's formalized. I don't know. – Felix Kling Jul 02 '14 at 09:08