When switching on Firebug's "Break on all Errors" mode in the console, it breaks on all kinds of errors which would actually not cause a real problem, even "assignment to undefined variable".
This results in lots of breaks inside jQuery and various jQuery UI plugins. It's so bad that I cannot use this feature at all, even though it would make debugging much less bothersome.
Am I the only one having this problem? If not, is there any workaround?
These are legitimate breaks you're seeing...for instance something like this:
undefinedVarName = "something";
Is not technically legal, and actually won't work in strict mode...you need to define a variable, even if it's at a higher scope before you use it, this is both good practice and...well...the correct way to do things.
The libraries themselves I've not come across the breaks you describe. Plugins? sure, if they're not well written they'll throw errors...you can either fix them or deal with it, but it's Firebug's job to complain about badly written JavaScript, and it's doing just that.
Related
I'm trying to get an angular.js/jQuery app running in IE8. I mostly have things working, but it spews a lot of console errors:
TypeError: 'undefined' is null or not an object
These errors in the developer tools don't have a source location (file & line) associated with them, and the debugger doesn't break on errors when these are being thrown, even if "Break on Error" is enabled.
Other than disabling portions of my code to search for the cause, is there any way to figure out where this is coming from? I'm getting dozens of them in every Angular digest cycle, so it's not as straightforward as figuring out what page actions cause them.
It's not obvious what, if anything, they're breaking on the page, but I haven't yet had the ability to test the whole thing, so it's hard to conclude they're benign; even if they are, I'd prefer to get rid of them; they're noisy and I'm concerned that they may be visible to the user under some IE error-handling configurations.
Though I've never used it, I've heard that DebugBar is an improvement over the standard IE8 developer tools.
Also, as JJZabkar mentioned in the question comments, Angular versions below 1.3 require certain shims to be in place to work with IE8 or below.
Another thing to be aware of, which is also described at that link he provided (https://docs.angularjs.org/guide/ie), is IE8's lack of support for custom element tags, which will foil any use of element-based directives (possibly causing errors) if you do not take certain measures.
Asking the right question (yep, the one held too stupid to be uttered) has it's own challenges. Since having started to flirt with d3.js, I seem to have no shortage of these. Here's one which, though for me quite pressing, I've already been warned may be too subjective.
Sometimes a DOM structure conflicts with what is expected: certain elements are perhaps siblings rather than children (perhaps the result of some filter function), or appear to be missing entirely (say an element which for some reason is being ignored).
In these cases, the DOM inspector can, though not necessarily misleading, be a frustration, and we are left to troubleshoot using the console and logs.
Sometimes, however, the console itself seems of little help. I'm thinking of those instances where you're confronted with a series of brackets, perhaps a hint at data, but -frustratingly- a series of error messages when trying to access it.
I see plenty incidental wildfire, but wonder is there a more or less comprehensive guide somewhere to the interpretation of cryptic console output, covering topics such as:
How the various object types are represented
What approach serves best to interrogate each
How to interpret various configurations of empty, square, curly and other brackets
Strategies for penetrating deeper regions of the DOM tree
Slights of hand to improve console representation and readability
Interpretation pitfalls to be aware of
Glad of any good leads..
Thanks
one really grat start is to follow these tutorials and introduction on d3.js:
http://alignedleft.com/tutorials/d3
in particular this section explains arrays and how they work:
http://alignedleft.com/tutorials/d3/data-types
I think this should be really helpful if you're just starting with d3
Something that may help for some of the cases you've mentioned for D3 specifically is the DOM inspector that vida.io (tutorial here) provides. In general, there's no answer to your questions however -- all depends on the particular library you're using, browser, versions, etc.
As an alternative to command line usage (e.g. console.log()) maybe the interactive web inspector would be more helpful to you. Details for Safari or Chrome. Although I find it less useful, there's also Firebug if you prefer Firefox.
I have written some Javascript (specifically a jQuery plugin) in which I replace the contents of some tags with the result of an eval to give me some kind of templating mechanism.
My question is: Will using eval() over and over cause a problem with memory?
The reason I ask is that when I look at the loaded scripts with Firebug, I see all the eval'ed code listed there, so my worry is that if the user uses this application in the browser, it might cause a problem with memory.
Apart from it being a bad idea to use eval, there will almost certainly be some memory overhead in setting it up.
Also eval code won't be as optimised** as there is no chance for caching or other optimisations.
** depending on browser.
Working with Extjs, GeoExt and OpenLayers, I more and more tend to run into problems which do not result in direct javascript errors (in either IE, FF or similar). It could be features not working, unexpected behaviour and so on.
My usual strategy is to strip down code to a minimum hoping to discover where the problem arises - Firebug and the IE debug tool are usually great companions. Google and various forums are always a big help – IF a similar problem has been documented by another user and IF the problem has been formulated in a way so that I find it.
But when it comes to using larger frameworks such as Extjs and OpenLayers, I find it very difficult when my debugging leads me inside the frameworks world of mysterious methods.
Asking questions here and in other forums can give fantastic results, but sometimes I cannot point to what the problem actually is – only the result I see on the screen. Using multiple frameworks it could be interference between them, unexpected behaviour when using exactly those frameworks and generally just complicating the debugging.
What do you recommend I do in these situations? What do you normally do – I would love to pick up a trick or two :)
I feel your pain. I use YUI a lot and sometimes errors get sucked into a bottomless pit of YUI code that doesn't generate an error per se but also doesn't do what I think it should.
In cases where I'm lucky enough that an error is thrown inside foreign code I look at Firebug's call stack and start debugging at the first place up the chain where I find my own code.
In the case of the bottomless pit swallowing errors then I resort to setting breakpoints in my code at suspicious places and single-step my way through.
Firebug is very, very useful here since it allows you to dynamically set breakpoints and conditional breakpoints. In both cases above I never reduce my problem to a minimum because the bug may be due to the complexity. Also, setting breakpoints is much easier.
About the only time I reduce my problems to a minimum is when I need to post it here or at comp.lang.javascript.
Now, if the bug only appears in IE I usually give up for the day, go home and come back tomorrow. It is a surprisingly effective strategy until my boss decides that we need to push the code to live TONIGHT (in which case I just cry inside).
Using the tiny Diggit/Blog feature of StackOverflow described here:
I would like to post the following Google tech talk video I have just saw and that I found quite interesting.
I have always had problems understanding javascript "nature".
Here, the JavaScript good parts are described by Douglas Crockford
I hope you find this link useful.
Now the question part:
What are your complaints about javascript?
Do you use an IDE for javascript editting?
Do you think this video helps to understand the "good parts"?
JavaScript: the bad parts.
The biggest mistake is late error detection. JavaScript will happily let you access a non-existant object member, or pass the wrong number of arguments to a function, and fill the gap with ‘undefined’ objects, which, unless you deliberately check for them (which is impractical to keep doing everywhere), will cause an exception or generate an unexpected value later on. Possibly much later on, resulting in subtle and difficult-to-debug errors appearing nowhere near the actual problem code. These conditions should have generated exceptions, except that JS didn't originally have exceptions to raise. ‘undefined’ was a quick and dirty hack we're now stuck with.
Undeclared variables defaulting to global scope. This is almost never what you want and can cause subtle and difficult-to-debug errors when two functions both forget ‘var’ and start diddling the same global.
The model of constructor functions is weird even for a prototype-based-OO language and confuses even experienced users. Forgetting ‘new’ can result in subtle and difficult-to-debug errors. Whilst you can make a passable class/instance system out of it, there's no standard, and most of the class systems proposed in the early tutorials that people are still using are both desperately inadequate, and obfuscate what JavaScript is actually doing.
Lack of bound methods. It's utterly unintuitive that accessing “object.method” when calling it makes a magic connection to ‘object’ in ‘this’, but passing “object.method” as a reference loses the connection; no other language works this way. When this happens, ‘this’ is set to an unexpected value, but it's not ‘undefined’ or something else that would raise an exception. Instead, all the property access ends up on ‘window’, causing subtle and difficult-to-debug errors later.
There is no integer type. Number looks like one but breaks down in various ways (eg. n+1==n for high enough n). Any time a NaN or Infinity sneaks in (quite unexpectedly if you think you are dealing with integers) you won't find out immediately; instead there will be subtle and difficult-to-debug errors down the line.
There is no associative array type. Object looks like one but breaks down under various unexpected keys. Arrays aren't pure lists. Any time you ever use ‘for...in’, you have probably fallen into a trap, and will experience... yes, subtle and difficult-to-debug errors.
Generally poor string handling, for a scripting language at least. String.split(, limit) and String.replace() don't do what you might think, causing... you know. The results of toString() are generally poor and not useful for debugging. Meanwhile we are stuck with a load of rubbish Netscape thought might be useful, like String.prototype.blink(), and the perpetually broken escape(). Yay.
And then there's all the browser differences (IE is still missing a lot of essential methods on the basic objects), and the DOM...
And finally, even when an exception does occur, it is hidden away from view, so the author won't even realise something is wrong. The result is that most sites are chock full of errors; turn on full JavaScript error reporting in IE and the result is unusable.
It scares me to think a new generation of programmers are learning this tosh as a first language. What's worse, most of the tutorial material they're learning from (“My fiRST AEWsome R0LL0VERZ!”) invariably encourages the worst possible practice. ‘javascript:’ URLs, ‘eval()’ for everything, browser-specific DOM access... oy.
The hard part about javascript, in my opinion, is:
Cross browser development/debugging issues
Cross browser dom/model issues (event bubbling, etc...)
Lack of "classes" (subjective)
Lack of good solid debugging support in browsers
Firebug helps a lot for FireFox, but I have not found anything that good for IE - and the mere fact that one has to is difficult.
On the bright side, if you build a script from the ground up and understand each step, it can be really enjoyable and powerful.
alt text http://oreilly.com/catalog/covers/9780596517748_cat.gif Javascript the Good Parts is a pretty decent book too.
For Javascript Firefox+Firebug and Notepad++ are my IDE. jQuery (and assorted plugins) is my Framework. My biggest complaint about Javascript is IE6
My biggest complaint while using JavaScript are the DOM bindings, but those are not really the fault of JavaScript so much as each browser implementing it their own way. Along those lines, IE is the worst offender.
In terms of pure JavaScript issues, I still don't fully grok prototyping in a way that allows me to use its full power; but that's less a complaint than my own personal failing. As a language I like JavaScript a lot, and any complaints I have on it are overshadowed by its interactions with the DOM.
I use Firefox + Firebug intensively for my main coding and debugging. There are debuggers in Opera and Safari that I use if either browser is having particular issues. Heaven help me when I need to debug IE.
I code in whatever text editor is available and has syntax highlighting. I tend to use the YUI framework, but that's just because I know it the best; I hope to someday learn more about other frameworks and decide which would be best for personal projects.
While I haven't seen the video, I just read "The Good Parts" this week. If the video is anything like the book, it'll be very helpful. The book itself is great because it's concise and informative. It goes into a level of language discussion that one doesn't see often enough when Googling for information, that gives one a better comprehension of the language as a whole.
I really like prototyping, it feels much more powerful than normal classes.