Tip: never return in a 'finally' block

This one has had me a couple of times. When you return in a finally block, Vexi will not log the exception because the return indicates that the function or trap has concluded successfully.

The symptom is code not being executed fully - a premature stop somewhere. The premature stop to the code path is caused by an exception, e.g. accessing a property on a null object.

var somefunc = function() {
    var nullobj;
    nullobj.foo = "bar"; // error!
    return true;
}

/** misguided function to return true on success, false otherwise */
var sometest = function() {
    var ret = false;
    try { ret = somefunc(); }
    finally { return ret; }
}

Of course the above code path does look, as described, misguided. However in more complicated scenarios, especially when working with RPC, it can be easy to forget the intended notion of a finally clause - to clean up necessary resources - and slip in a return. Mostly it will be harmless but on the occasions that the code path embedded in the try clause throws an error, you'll find yourself dumbfounded as to why your code path is not completing and why there is no indication of the problem.

There is a simple rule to follow to avoid this problem (which can take hours to diagnose!) and that is to either A) never 'return' in a 'finally' or B) always preceeded a 'finally' with a 'catch(e) { vexi.log.info(e); }' to make sure the error is logged.

HTH!

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.

Marketing Vexi

A revamp of the marketing message for Vexi is long overdue. At the moment, the front page of the Vexi website is just a bit of a technical mess. I need to work out exactly how to portray Vexi as a useful tool in today's market which is very favourable to Web 2.0 and not so favourable to technologies that fall outside of this misguided "inside the browser" paradigm. The message has to be much more subtle than simply stating that we believe everybody else is wrong, but it has to assuage that conclusion upon a visitor.

Technical advantages: integrated unit testing (VUnit), trap model, box layout, browser independence (Java 1.4 compatible), enhanced JavaScript (VexiScript), sandbox security, complete UI control, intuitive syntax, and more.

We can put these in a giant list and they'll appeal to some people, but to those whose mind is already made up, a different approach is required - illuminating the benefits brought to application development using a platform with the aforementioned technical advantages. Of course, examples are always good, and we have something major to show the world Real Soon Now (tm).

To be continued...

VUnit Explained

It has been said that languages without type verification don't need it because ultimately its just a limited form of testing and unit tests are a better way of doing things. Its fair to say that the argument is losing ground as people such as mozilla are looking at static type checking. Ultimately type information is much more than that, its also a way to navigate code. In any case Vexi ought to have its own testing framework, and as it turns out it does in VUnit, just not much had been written about it and how to use it. This is no longer the case, as i've updated the wiki with an explanation.

Vexidev 0.3.2

The latest release of the imaginitively titled eclipse plugin and vexi development environment 'vexidev' is now available. The new features are

• vunit launching

• library management