Archive for the ‘Developer’ Category

update: New version of the Javascript debugger

March 18, 2011

Although jsErrLog, my “Web Watson” has only been out a couple of days I had a great suggestion to let developers add some additional context to errors that are being trapped.

To support this I’ve added a new parameter that’s a string variable you can update at any time (after the library has been registered on your page of course) and the first 512 characters simply get passed through to the report database.

To use this new feature simply add a line that updates what you want passed through with the data you want passed and if the error handler gets called then the data will be transferred to the database = “Populated the Info Message to pass to logger”;

Any other features you think are worth adding?

Watson for the web – trapping Javascript errors

March 16, 2011

A while ago I wrote a small piece of JavaScript code that I needed to be able to integrate into lots of different sites to help streamline the Silverlight experience, but it was important that I didn’t break anyone’s existing code.

While we did extensive testing with the partners before we deployed it there was always the worry that a combination of browser and OS and plug-in we’d not tested would cause a problem we’d not foreseen.

As websites get more complex, and HTML5 brings more of the heavy lifting back to rely on JavaScript to build really dynamic experiences so my little nagging concern was just going to keep on getting bigger.

While you can wrap every statement in a Try…Catch loop and deal with exceptions that way it’s not the most efficient, and if you’re integrating libraries from a  lot of different sources then it’s not really practical.

As luck would have it two of the browsers had already implemented the key to the solution… the humble JavaScript window.onError function. In IE and Firefox it allowed you to attach an event handler that would kick in whenever an un-trapped error occurred and allow you do to whatever you needed to manage the problem.

I took that functionality and build a small script that could be injected via a single line of JavaScript into the page you want to monitor that would catch any unhandled error condition and report back to a remote cloud service the script, the error, the browser and OS versions so a developer could quickly and easily re-create the test scenarios. The code is available at jsErrLog.

Then because Chrome, Safari and Opera didn’t support the onError function I rather shelved the project. Just a few days though with the release of Chrome v10 another browser could be added to the support matrix for remote error reporting (and as the fix is in the WebKit core we can only hope that a release of Safari greater than v5 will roll out support as well)

While I wait for Safari and hopefully Opera to catch up with this I’m making a couple of other small tweaks to the code to make it a bit more reliable, as well as adding some extra functionality to allow developers to pass additional information back to the reporting database to help with debugging their specific apps.

Check it out , kick the tires and let me know if you have any feedback…