F.

http://code.google.com/p/jsdt/wiki/newFeatures

console.dir({
b:b,
bc:bc,
tableSelector:tableSelector,
tableStyle:tableStyle,
pad:this.getPadding(),
space:this.getSpace(),
width:this.getWidth()
});

I am able to set break point, but control is not coming there.

Please advise.

It has HTML, JS, CSS,XML,… editing helpers.
A very powerful javascript debugger.
An integrated web server, and… it is FREE!

I used it happily for years.
One sad thing, the XSLT debugging is not available in the free version.

As I moved to a Mac now, I switched to an Emacs-Firefox+Firebug environment.

I’ll look into Dojo’s debug mode. I wrote an article about rewriting console.log statements with a debug mode flag:

http://www.thetruetribe.com/2008/04/redefining-consolelog-for-browsers.html

in Dojo, we do have a flag for debugging being on or off, though we use this mostly for whether console.log and console.debug statements are executed with Firebug or Firebug Lite rather than a way of suppressing all exceptions.

Things that have served me well thus far are developing for Firefox first and foremost and patching for IE as necessary, and making extensive use of Firefox’s Firebug JavaScript console and debugger. Being able to set conditional breakpoints, log messages and check the state of the DOM at any point during execution is invaluable. I just wish there was something as full-featured for IE! In all fairness, there is a small offering by way of the Script Editor (and the even-worse Script Debugger). But, it doesn’t feature a fraction of the functionality or user-friendliness of Firebug.

As for shotgun debugging, one thing that my friend Lowell pointed out is that commenting out large blocks of code is easy if you use two slashes for your code (//). It’s more difficult if you use /* */ since each time you do that, you’ll need to add another opening comment. For this reason, he always uses two slashes for comments and uses the other style of multi-line commenting exclusively for commenting out code.

One other point in this discussion: Depending on the JavaScript library or framework in use, exceptions will sometimes be swallowed and the application will silently fail. This has happened to me quite a bit when using Prototype/Scriptaculous as well as at times with jQuery. Interestingly enough, MooTools seems to be really good at raising exceptions. Is there a philosophy behind this? For example, don’t raise the exceptions for users as it will cause an annoying error popup in Internet Explorer?

It seems that libraries would benefit from having a “development mode” flag that you set when you are coding the site, and turn off when deploying to the live production server. When the flag is on, exceptions would be raised, but you could disable it before deployment and errors would cause silent failure.

One final thought– do you do much error handling outside of checking an Ajax response from the server? I can’t think of many times where I would try() catch() something. Instead, if there is the possibility something would be undefined, I check if (typeof obj == “undefined”). It’s been working pretty well for me so far but I’m wondering what some cases would be that I might use error handling.

-Jonah Dempcy
http://www.thetruetribe.com

http://johnnydebris.net/projects/jsshell/jsshell.html