No Error for Malformed Groups in Regex in REPL #2746

ghost opened this Issue Feb 13, 2012 · 4 comments


None yet
3 participants

ghost commented Feb 13, 2012

When the REPL tries to execute a regex which contains a malformed group, it prints the same "..." it would usually print when the input contains a syntax error or is incomplete in itself. e.g.,

> 'hello'.find(/(h/);

This is less a problem when entering it directly in the same line, but it becomes a greater issue when the regex in question is in a called function, which could be in an included module, and runs counter to the usual meaning of "...", which is that immediate input is syntactically incomplete.

> function find_h(s) { return s.find(/(h/); }
> find_h('hello');

Instead it would be much more helpful if it printed an actual error (and stacktrace), something along the lines of what a browser might print, such as the following error message from Chrome:

SyntaxError: Invalid regular expression: /(h/: Unterminated group

Benvie commented Feb 13, 2012

The problem is likely that while both are syntax errors, a JS syntax error will manifest in a failure during the compile phase while a regex syntax error will compile and fail during execution.

A syntax error in JS will throw during vm.createScript(badCode) where a regex syntax error won't.


bnoordhuis commented Feb 13, 2012

@Benvie: Not quite. V8 reports it as a SyntaxError.

$ node -e '/(/'


SyntaxError: Invalid regular expression: /(/: Unterminated group
    at new RegExp (unknown source)
    at Object.<anonymous> (eval at <anonymous> (eval:1:82))
    at Object.<anonymous> (eval:1:70)
    at Module._compile (module.js:441:26)
    at startup (node.js:80:27)
    at node.js:551:3

However, this bug is probably not fixable in the REPL. The REPL evaluates the current line after each keystroke in a VM context until it sees a valid expression (i.e. until it doesn't throw a SyntaxError). That approach works reasonably well but it's easily fooled: try entering !;, for example.

Can someone review 4f38a86?

bnoordhuis reopened this Sep 22, 2012

Stupid GitHub closing issues prematurely...

@mortchek Thanks for the report, fixed in 4a26707. Will be in the v0.8.10 release.

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