SyntaxError objects should contain information about where the syntax error happened

[fresheneesz]

Consider these files:

test.js:

try {
    require("./testmodule")
} catch(e) {
    console.log(e.stack)
}

testmodule.js:

}

In this case, the result is the following text:

SyntaxError: Unexpected token }
    at exports.runInThisContext (vm.js:53:16)
    at Module._compile (module.js:413:25)
    at Object.Module._extensions..js (module.js:452:10)
    at Module.load (module.js:355:32)
    at Function.Module._load (module.js:310:12)
    at Module.require (module.js:365:17)
    at require (module.js:384:17)
    at Object.<anonymous> (/home/vagrant/temp/test.js:2:5)
    at Module._compile (module.js:434:26)
    at Object.Module._extensions..js (module.js:452:10)

Notice that it doesn't give you any information about what module that unexpected token is in nor what line in the module that unexpected token was found at. This makes it pretty hard to debug in cases where you're requiring a module somewhere other than at the very top of your source.

You can usually infer the module its in by looking at the line in test.js that it indicates, but if you have more than one module required in the same line, that won't tell you which one.

If you don't catch the SyntaxError, you get the following additional info:

/home/vagrant/temp/testmodule.js:3
});
^

This is super helpful (although it incorrectly contains some boilerplate - the ); that doesn't actually exist in the file), and should be contained in the error's message and stack properties. At very least, the error object should contain those two pieces of information somewhere.

[ChuckLangford]

This appears to be related to the following issue and pull request:
#2104
#2108

[tflanagan]

That ); is actually the code your module is wrapped with before being executed.

[fresheneesz]

@tflanagan Yes I expected that to be the case, but it still ideally shouldn't appear in the exception.

[nouex]

Also related to issue #2762

[setthase]

+1 for fixing this.

I spent half day trying to fix things in a wrong file...

[matthewloring]

@fresheneesz This should be fixed by #4874. Can you confirm this issue is fixed on master?

[cjihrig]

This was fixed in v6, and the module wrapper was documented. Closing.

[ghost]

I don't understand why this is closed.. This is still an issue in Node v8.x

[gibfahn]

I don't understand why this is closed.. This is still an issue in Node v8.x

This was closed because #4874 landed as 5700352. That commit has been in every Node release since 6.0.0 (including all 8.x releases).

If you're still seeing this issue could you provide more details? Ideally let us know why 5700352 didn't fix your problem.