Debugging Vexi Applications II

As we've used Vexi over the last year, we have added little features here and there to help us get the most of out it.

I'm always mindful of performance, so I don't like to use the 'try/throw/catch' method from the previous debugging tip in production code. However chopping and changing code in a complex environment can be a pain, especially when you are working with code that has a far reaching impact and you want to be able to get a general sense of what is happening as you use your application.

For this, I added the 'vexi.debug' property. A simple boolean on the Vexi object, which can be enabled by either running vexi with the '-debug' flag or by putting 'true' or 'false' to the 'vexi.debug' property.

This way, we can wrap fairly complex debugging operations in an if statement and avoid them in normal running. For instance, we introduced 'vexi.js.stringify(arg)' which takes a JS object and returns it as JSON. Doing this in heavily run code can be a bit of a waste of CPU power, but at the same time JSON is much more useful for debugging than the type/hash representation (e.g. object$1ab23e) of non-primitives.

if (vexi.debug) {
    var o = anExpensiveOperation();
    vexi.trace(info);
}

Also, there is the call to vexi.trace which is another new function. It is shorthand for:

vexi.log.info(vexi.js.stringify(o));

Of course, the ideal way to avoid days of debugging headaches is to do proper unit testing. It takes time to get it right, but once you have a non-trivial application, a suite of tests can save you no end of trouble and make sure your application remains solid after major changes to the code. See the VUnit documentation for more information on how to create tests.