镜像站点 · 本页由第三方 GitHub 只读镜像提供,非 GitHub 官方站点,不接受任何登录或凭据输入。前往 github.com
Skip to content

SyntaxError objects should contain information about where the syntax error happened #3411

Description

@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.

Activity

  1. added
    vmIssues and PRs related to the vm subsystem.
    on Oct 16, 2015
  2. ChuckLangford commented on Oct 18, 2015

    @ChuckLangford
    Contributor

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

  3. tflanagan commented on Oct 19, 2015

    @tflanagan
    Contributor

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

  4. fresheneesz commented on Oct 19, 2015

    @fresheneesz
    Author

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

  5. nouex commented on Oct 19, 2015

    @nouex

    Also related to issue #2762

  6. setthase commented on Nov 23, 2015

    @setthase

    +1 for fixing this.

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

  7. matthewloring commented on Apr 12, 2016

    @matthewloring

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

  8. cjihrig commented on Jun 16, 2016

    @cjihrig
    Contributor

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

  9. gibfahn commented on Jul 22, 2017

    @gibfahn
    Member

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    vmIssues and PRs related to the vm subsystem.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions