One of the persistent problems I have when debugging javascript is that should the compiler find an error and put it on the console, the error tends to get lost. The reason being that most of the standard libraries have hundreds of console errors in standard firebug consoles. I use jQuery, bootstrap and Angular and the all produce lots and lots of noise in the console window, that makes it hard to find the real errors.
When I compile code I always clear out ALL warnings so that errors are more evident. But there doesn't seem an easy way to do this in JavaScript.
Any thoughts?
If you think instead of a flat view, an indented view of console logs might help you, you can try using console.group("Group Name") to start a new indentation block and console.groupEnd() to close it.
You can create such indented groups for different phases/interactions in your code, which might make it a little easier to read the logs as they will be nested under the "Group Name" used to create the group.
Related
Is it possible to track errors in polymer.js in a strategic way? Somehow I don't get any error-messages or Exceptions. In case of Errors, Polymer just does nothing if I'm doing something wrong.
For example, if I add the property disableSwipe to paper-drawer-panel, it is ignored, but there is no error-message or logging that could give me a hint what is going wrong. (I still don't know why, but this is offtopic)
Is there any way to activate some Kind of strict-mode that would cause Polymer to throw Exceptions in case of an error, or at least activate some logging that would show error-messages?
Debugging without errorMessages feels too much coincidence-based to me.
Someone else beat you to this complaint and filed an issue with Polymer.js.
https://github.com/Polymer/polymer/issues/3367
I searched through the Polymer project and there is no mention of error handling or exception handling or increased verbosity levels, and until they code something in to implement those features, you'll be left with the default javascript runtime, coding blind and with poor mans debugger.
As an alternative, the polymer.js people recommend using polylint, which won't give you information about runtime errors or exceptions, but instead a static code analysis analyzer, and it might not find your exception because your error might be some off-by-one error that static code analysis can't find.
https://github.com/PolymerLabs/polylint
That's a bad code smell and strike against Polymer.js If you can't bother to put in proper exception reporting and error handling, I can't be bothered to use your product.
The best you're going to get other than polylint is whatever the google javascript developer tools embedded in google chrome browser gives you:
https://developers.google.com/web/tools/chrome-devtools/inspect-styles/shortcuts
That will give you warnings and errors, but that's only if the polymer.js devs wrote an actual bug. If it doesn't halt on an error or warning, you're left to inspect and watch the javascript code line by line, and try to guess what went wrong by reading the Polymer.js source.
Trying to learn React.js right now but I'm having a lot of trouble with syntax errors. It is not clear to me how to debug JSX when writing react.js code. A typical JSX syntax error will look like this on my console:
"Line 15" does not appear to correspond to any actual code. In my IDE it's a blank line right before my <script> tag. Expanding the error simply shows a couple dozen references to JSXTransformer.js.
When I google this issue, everyone says to simple install the React debugger, which I did, but it is useless when it comes to JSX syntax and won't actually start:
Others have suggested using debugger; calls in my scripts to call the Chrome debugger, which is sensible, but the JSX error somehow halts the script no matter where I put the call.
React has significant trouble with identifying the offensive lines, it's very likely the one before, in your case line 14.
For those still looking for a quick fix to the broader question posed in the OPs title, consider an inline debug statement in your JSX.
<span>{ console.debug('test') }</span>
This should output a message in your console either before or after the existing error you are attempting to locate. Move the above code up or down in your JSX then refresh and check your console again to narrow down on the location of the error.
It's not ideal but it works. This method will display the word 'undefined' in your resulting HTML so make sure you remove your debug code when you are done.
I'm a beginner at Javascript, and I wrote some code that works perfectly, but generates a console error from time to time.
It's a coin flip simulator, where the class of the coin needs to change depending on the outcome- so it searches for the opposite outcome class name and changes it to the current outcome class name (using SetAttribute). However, sometimes you get two of the same outcomes in a row, so searching for the opposite class name returns null, and then I get an error for trying to setAttribute of null.
I could write an If statement to avoid this, but I'm wondering if that's necessary. I want to learn best practices, so please, if there's a reason to avoid console errors, let me know!
Console errors such as an unhandled exception indicate a problem in your code. Sometimes the problem might turn out to be benign, but there is no way to know if its benign without studying the code. And, by the time you have studied the code to understand the problem, it is usually one or two lines of code to avoid or handle the problem in your code.
You should add this extra code to handle the problem because if you let these benign warnings build up, then pretty soon you won't be able to notice a new warning pop up that is actually a sign of serious trouble. Your code should be exception free precisely for this reason so when an unexpected issue shows up, you can clearly see it and both you and everyone else working on the project or testing the project knows that a warning like this is unexpected.
So, it is a good practice to clean up all warnings like this and keep your code clean and warning free.
Imagine you were driving your car and a warning light came on. You take it into the mechanic and the mechanic says: "oh, that's how they designed it - the light comes on from time to time". OK, now the warning is basically useless because you don't know when a warning is a sign of a real issue and when a warning is just some incomplete design that didn't clean things up well. It's the same with your code.
I am finding it difficult to locate where an error occurs in javascript on a client I have no access to. Currently I trap the error with onerror and send the arguments to a log on the server.
Unfortunately the line number is no help because numerous javascript files get included, causing the line number to not correspond to anything I have access to.
So if I get something like "n is not defined", and n occurs many times in the function, I have no way to locate where it happened.
I have been trying to reference the code on the line throwing the error say "x=n * 5 + 4", then I could search for that code, but have had no luck referencing the actual code on a line from within javascript.
So how does one locate the line that threw the error in this situation?
client uses firefox only, if that matters.
I have no access to client
This is not one error I am stuck on, but working on how to track an error in this situation
Your best bet would be to use Firefox's debugger.
Open dev tools
Go to the debugger, select the .js file you want, and hit the little {} button in the bottom left (depending on version yours may be in a different location) -- this will prettify the JavaScript
Set breakpoints by clicking next to line numbers
From here on out you have to do this old-fashioned. Cast a breakpoint net around your trouble code, then keep narrowing down the lines until you find the occurrence that causes the error.
Of course, once you find the line it still won't be 1-to-1 with the original code, but hopefully the breakpoint exercise will at least reduce the scope of code/logic you have to dig through.
use your debugger to enable breaking on error. once you break, look at your locals for clues about your location. go up the stack and look at each frame.
you should be able to trace n up the stack and find out why it was null
the little {} that william suggested is also helpful
I need to modify WebDriverJS for my purposes. The compiled source is giving me a hard time debugging, though. Describing function names and comments would help me out big time! So I was wondering whether it is possible to compile WebDriverJS without minimizing it's content.
The build.desc for the JavaScript compilation is using js_binary which is using Google Closure Compiler. Anyone of you know how to compile it and preserve functionnames and comments? This would rather be a merge of all sources then a compilation.
Thanks to Chads Post in "Potential differences between compiled and uncompiled Javascript" I've taken a deeper look at the flags of closure compiler.
--compilation_level=WHITESPACE_ONLY preserves function and variable names
--formatting=PRETTY_PRINT doesn't remove linebreaks
--formatting=PRINT_INPUT_DELIMETER gives me a better overview in which file to search for the source
Unfortunately I still couldn't figure out how to save the comments, but thats just a small problem since I can look them up in the source code.
Update:
Seems like the compilation_level doesn't remove the goog.required-calls. I've got to remove them somehow, because the script doesn't work with them.
Update 2:
I've removed all goog.require($mod) and goog.provide($mod) calls and defined Objects where needed (typically to find right after the // Input $int comments). It's working now.