New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 617456 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner:
Last visit > 30 days ago
Closed: Jul 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Feature



Sign in to add a comment

Very poor parse error information for "missing ) after argument list"

Reported by teo8...@gmail.com, Jun 5 2016

Issue description

UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.79 Safari/537.36

Steps to reproduce the problem:
See the error in the screenshot

What is the expected behavior?
The error message should show where the error in the code is, and what kind of error it is

What went wrong?
I'm sure there's a syntax error in my code (most probably an unmatched parenthesis somewhere), but it's certainly either not where the message says it is, and/or not the kind of error it says it is. 

This error is effectively equivalent to "Parsing error somewhere in your code", that is, completely useless.

Now I do perfectly understand that reporting parsing errors in a human-meaningful way is tricky, that "properly locate where and what the error actually is (from the point of view of the coder)" is not a well-defined problem and that the parser does not work the way the programmer's mind does.

However, the quality of the error message is just unacceptably low here. And it can EASILY be improved, at the very least, by pointing out where the "argument list", which the parser expects to end with a parenthesis, starts. That would be trivial and would help locate the real problem in almost all cases.

Did this work before? N/A 

Chrome version: 51.0.2704.79  Channel: stable
OS Version: 
Flash Version: Shockwave Flash 21.0 r0
 
Screenshot from 2016-06-05 20-07-30.png
98.5 KB View Download

Comment 1 by teo8...@gmail.com, Jun 5 2016

The error in this case is caused by a missing { after the 'if' statement at line 235, and I totally understand why the parser detects the error it detects where it detects it: the code snippet is inside a call to 
  $.widget("widgetName", { /*...*/ });

However, I insist, if the parser tells me an argument list finishes unexpectedly, it MUST tell me which argument list it is, that is, it must point me to the opening ( where the argument list started.
Components: -Blink Blink>JavaScript
Cc: seththompson@chromium.org adamk@chromium.org
Components: -Blink>JavaScript Platform>DevTools Blink>JavaScript>Runtime
Labels: -Type-Bug Type-Feature
Status: Available (was: Unconfirmed)
Cc: yangguo@chromium.org
Components: -Platform>DevTools
Status: WontFix (was: Available)
From the code snippet you provided it's hard to figure out what's going on. I can only guess: you are defining an object literal with methods, one of which is _init, _cleanUp is another one.

Due to the missing bracket it looks like the object literal that should contain both _init and _cleanUp ends right after _init, and _cleanUp comes after the object literal.

Presumably, you have something like

foo({ _init: function() {...} }, _cleanUp: function() { ... })

Now, to the function call to foo, the first argument would be the object literal, the second one would be a variable called _cleanUp. We would now either expect a comma for more arguments, or a closing bracket. Instead we have a colon. The syntax error position points to the end of _cleanUp, which is totally reasonable.

So I don't think there is any other way to parse this, unless you expect the parser to take indentation into account.

Comment 6 by teo8...@gmail.com, Jul 29 2016

Have you even read my comment 1?


Owner: kozyatinskiy@chromium.org
Well there is no good way to provide and show two locations for a syntax error. Adding the colum and line of the start of the argument list doesnt seem like a good solution either.
Alexey, do you have a better idea how to visualize two locations for the same exception in Devtools?

Sign in to add a comment