Within Google Chrome, I was wondering if stack traces will, in the future, provide mapping support. Currently, using source maps, throwing an error will provide the line number link to my TypeScript files, however... When calling the Error.stack, it gives me the JavaScript lines and files.
Here's a reference picture: http://puu.sh/4DTOG.png
As you'll notice, the actual line the error is on is linked to the TypeScript file, but the stack trace links to the JavaScript files.
This bug is fixed in chromium 42 :)
Cf https://code.google.com/p/chromium/issues/detail?id=357958 .
There is no inherent technical limitation. However I don't think it is planned. For reasons like, when the stack trace contains code that is not TypeScript (or lacks a sourcemap) etc.
Related
Netbeans considers for await syntax to be invalid. The error hint indicates: "Expected ( but found await". Source > Format will not work as expected while the for await remains.
Is there a way to update the existing syntax checker for .js files to mark for await as valid syntax, so that the code formatter will work correctly again?
I tried to review FAQs on the official site for Netbeans. All the relevant questions lead to page not found dead ends.
I tried to go to Tools > Options > Miscellaneous > Files to edit the associated file config for js which defaults to text/karmaconf+javascript. It's possible to change the file type, but not to edit the existing one. I searched the netbeans program files path for the config file to update it manually, but I don't quite know how to find it.
I can reproduce your issue in NetBeans 16, and it has already been bug reported. See NetBeans Bug Report #4757 JavaScript to support "for await of" #4757.
You could opt to filter out the parsing error:
However, that approach would probably cause more problems that it would solve. While it would make that "Expected ( but found await" message go away, at a minimum it would also impact the parsing of the entire file, and would not impact formatting at all. (I realize that was not part of your question, and mention it only for completeness.)
Apart from that, all you can really do is update the bug report to voice your concern in the hope that it increases the priority of fixing the bug.
Unfortunately I don't see any way to resolve the issue through configuration changes in NetBeans.
I try to optimize the performance of a node.js application and therefore I am analyzing the behavior of V8's JIT compiler.
When running the application via node --trace_deopt --trace_opt --code_comments --print_optcode ..., the output contains many recurring lines like the following:
[didn't find optimized code in optimized code map for 0x490a8b4aa69 <SharedFunctionInfo>]
How can I find out which javascript code corresponds to 0x490a8b4aa69?
The full output is available here.
That error message used to be around line 10200 of v8/src/objects.cc, but is no more. It basically means no optimization was currently employed for a particular trace. Possibly because it was unused, or used sufficiently infrequently. It may have likely been a Node.js library function. The address provided is in memory. You'd have to have attached a debugger to v8 and load the symbol for the SharedFunctionInfo at that location. Possibly breakpoint on the line that produces the message too.
I don't think it is that useful to know what was not optimized, as there are lots of things that don't get optimized... just take the output from --trace_opt and assume everything else isn't. It was kind of just a hint that a check was performed for optimized code, and none was there are the time. Maybe try --trace_codegen and work backwards.
This looks to be a very time consuming thing to research.
Thorsten Lorenz would be the guy to ask about this.
I have a script that uses Raphaël, a Javascript library to work with SVGs. In my code I am doing something wrong because of that I am getting a warning from the library.
That warning comes from some line in the library. It would be great to trace the stack from when that warning occur to know where in my code is the line that causes the warning.
Using console.trace doesn't help, so I ask, is there a way to trace a warning that comes from a Javascript Library?
(PS: I looked into modifying the library to print stack traces, but that is just too hard.)
Edit:
The warning itself is:
"Unexpected value NaN parsing width attribute."
I would like to trace the error to know where in my code am I sending a NaN to a Raphael function.
If I'm right, your warnings are probably something like "Invalid syntax M,0,0" when you're trying to create paths (more details would be welcome) ?
If it is, then you can't have a stack trace because it's an SVG error (the SVG engine is telling that a DOM SVG element is erroneous, but it won't tell you when this node has been created).
Check the input that you're feeding into the elements that you are creating with Raphael.
I am in the process of ironing out my codebase so it can compile with ADVANCED_OPTIMIZATIONS on google's closure compiler.
After properly setting up the debugging environment required for this task (source map file, chrome, wrapping the compiled js file) i stumbled upon try catch issues. It appears that extensive use of try/catch statements in my codebase has backfired on me.
On almost all methods and functions i use a typical try { } catch(e) {ss.error(e);} statement, where ss.error() is a generic error handler that depending on environment either prints out debug stuff or reports back the exceptions...
In the process of ironing my codebase, when i get an error that i need to fix, what happens is that instead of having Chrome report the offending file and line, it points to the error handler ss.error(). Thus leaving me with no way of backtracing the problem. The ss.error() func however, does print where the problem originated from:
Error! type:TypeError at Db (/jsc/compiled.js:547:246) msg:Cannot call
method 'ka' of undefined source:
After i get these type of errors i have to do two steps:
1. Fiddle with the compiled code at line 547 char 246 and try to figure out which part in my uncompiled code this refers to...
2. After i locate it, remove the try/catch blocks so i can directly and more clearly see what caused the error...
I must say i am not happy with this workflow and need to find an alternative that will both allow me to properly catch exceptions and debug my compiled and uncompiled code while retaining mind sanity =)
I was thinking of somehow using the Line:CharPosition info to query the source map and have the ss.error() function do the mapping to my uncompiled source code...
ideas?
There is a java interface to the SourceMaps as part of the closure compiler. There are also JS implementations in various states of repair. I try to keep links to them up to date here:
http://code.google.com/p/closure-compiler/wiki/SourceMaps
For the Java implementation you simply load the source map using the SourceMapConsumerFactory, the interface is pretty simple.
I've built a custom logging utility which displays a Log Message and the DateTime. I would like to add the line number in the source code which called the function.
Is there a way to determine which line of the HTML source a particular javascript function was fired?
Having written a logging library (log4javascript) myself, I've considered this same problem and here are my thoughts:
The problem is that in order to get the information you want, you need an Error object that was created on the line in question. Creating an Error within your logging utility will only directly give you the filename and line number for the particular line in your logging utility code rather than for the line of code that made the logging call. The only way round this I can think of is parsing the stack property of the Error (or the message property in Opera), which has several problems:
the stack trace is only available in Mozilla, recent WebKit and Opera browsers
the stack trace is a string that varies from browser to browser, and may change format again without notice in future browsers, thus breaking the parsing code
throwing an Error and parsing its stack trace for every log call will add a significant performance overhead.
For the purposes of log4javascript, I decided it wasn't worth implementing, but for your own needs you may decide it's worthwhile.