require(): no information about where error

[amurchick]

When errors in require()'d file:

$ node -v
v5.0.0
$ node
> require('./auth')
SyntaxError: Unexpected identifier
    at exports.runInThisContext (vm.js:53:16)
    at Module._compile (module.js:404:25)
    at Object.Module._extensions..js (module.js:432:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:311:12)
    at Module.require (module.js:366:17)
    at require (module.js:385:17)
    at repl:1:5
    at REPLServer.defaultEval (repl.js:248:27)
    at bound (domain.js:280:14)

I am understand - error in auth.js, but no info where error occurred was provided - files sometimes big and no quick way to localize error.

Early - some useful diagnostics was provided:

$ node -v
v0.12.7
$ node
> require('./current')
/path/to/file/current:1
unction (exports, require, module, __filename, __dirname) { 2015-11-11_23:04:3
                                                                    ^^
SyntaxError: Unexpected token ILLEGAL
    at exports.runInThisContext (vm.js:73:16)
    at Module._compile (module.js:443:25)
    at Object.Module._extensions..js (module.js:478: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 repl:1:1
    at REPLServer.defaultEval (repl.js:132:27)
    at bound (domain.js:254:14)
> 

[evanlucas]

you should be able to run node -c <file> to do a syntax check.

[thefourtheye]

@amurchick I believe this is specific to REPL. Can you please confirm if my understanding is correct?

[cjihrig]

It is REPL specific.

[Zirak]

Looking into it a bit, the difference between requireing the file and loading it directly is interesting.
The require flow goes through loading the file and then calling node::ContextifyScript::New (vm.js, node_contextify.cc) which propagates the SyntaxError to the javascript-land caller.

On the other hand, towards the end of the regular load's flow node::ReportException is called, which prints the origin of the exception from a hidden value: arrow = err_obj->GetHiddenValue(env->arrow_message_string());

The naive first thought will be to call ReportException in ContextifyScript::New , but that means the error will be printed even when the exception is caught.
The better second thought will be to expose the currently hidden value on the error object, but that'll single out node as the only environment to have this behaviour.
The even better third thought will be to expose ReportException as a binding, and have repl call that on uncaught exceptions. That'll not only solve this issue, but also give more detailed errors on regular errors, which may or may not be desirable.

Thoughts?

[amurchick]

@thefourtheye @cjihrig - it is NOT REPL specific. Try this:

$ node -v
v5.0.0
$ cat test.js 
try {
    var a = require('./auth');
} catch (e) {
    console.error(e.stack);
}
$ cat auth.js 
module.exports = {
    a: 10
    b: 15
};
$ node test
SyntaxError: Unexpected identifier
    at exports.runInThisContext (vm.js:53:16)
    at Module._compile (module.js:404:25)
    at Object.Module._extensions..js (module.js:432:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:311:12)
    at Module.require (module.js:366:17)
    at require (module.js:385:17)
    at Object.<anonymous> (./test.js:2:10)
    at Module._compile (module.js:425:26)
    at Object.Module._extensions..js (module.js:432:10)

[cjihrig]

Ah, sorry. Misunderstanding. I meant that the legacy behavior is there if you don't catch the error. For example, if you drop the try...catch in your last code sample. It comes down to the ReportException() difference, as explained above.

I would like to work on this, I'm just trying to figure out what the best approach would be. Exposing ReportException() seems like it would require a good bit of work, since that function is pretty much hard coded to use the process stderr, while the REPL can print to arbitrary streams. I think all we really want is the hidden arrow message string, but it feels a little hackish to expose a function just for that.

I'm willing to do the work once it's decided how we want to do this.

[Fishrock123]

Is this possibly related to #2860?

[cjihrig]

I don't think so. #2860 looks to be related to the module wrapper causing incorrect offsets (#2867 appears to be a fix for that one, and I'm going to look into today).