ciplogic.com
Live with grace. Write superb software.

chrome

  • JavaScript Exception Handling HowTo

    A very used paradigm when it come with dealing with errors is the try/catch construct.

    In JavaScript you can throw anything as an exception, and in your catch statement you will receive that object instance that you threw. This is pretty cool, because when you receive the catched object, it might contain valuable information on what actually went wrong. In most cases though people just pass a string with the error message.

    I've seen advanced programmers actually throwing the message itself as the thrown object, in code that I will simplify as this:

    1
    2
    3
    4
    5
    6
    7
    try {
        console.log("computer reports heating at engine 1.");
        throw "oh man, catastrophic failure at engine 1.";
    } catch (e) {
        console.log("last words were:", e);
        console.log('the time backtrack saving device took note of the missing ship.');
    }

    Output:

    1
    2
    3
    computer reports heating at engine 1.
    last words were: oh man, catastrophic failure at engine 1.
    the time backtrack saving device took note of the missing ship.

    Unfortunately this is a problem, since we got the error message, and it looks good in our 7 lines of code. In reality if our program was a bit bigger, our message was now meaningless, since we would need to find from where the thing was thrown. If the code that can cause the catastrophic failure is called from multiple sites, this only adds to the complexity.

    This is why you always use the Exception object. The Exception object is part of standard JavaScript, and in all browsers,Chrome, Firefox, and IE from version 10 onwards (no one uses IE9 on their space ship anyway) has an extra property, named stack, that gives you the stack trace:

    1
    2
    3
    4
    5
    6
    7
    8
    try {
        console.log("computer reports heating at engine 1.");
        throw new Error("oh man, catastrophic failure at engine 1.");
    } catch (e) {
        console.log(e.stack);
        console.error("the pilot warning message was:", e);
        console.log('the time backtrack saving device went back in time and send a bot to fix the engine.');
    }

    This gives the output:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    computer reports heating at engine 1.
    Error: oh man, catastrophic failure at engine 1.
       at window.onload (http://fiddle.jshell.net/_display/:26:5)
    the pilot warning message was: Error: oh man, catastrophic failure at engine 1.
       "the pilot warning message was:"
       {
          [functions]: ,
          description: "oh man, catastrophic failure at engine 1.",
          message: "oh man, catastrophic failure at engine 1.",
          name: "Error",
          stack: "Error: oh man, catastrophic failure at engine 1.
       at window.onload (http://fiddle.jshell.net/_display/:26:5)"
       }
       
    the time backtrack saving device went back in time and send a bot to fix the engine.

    So please always use Exception objects and avoid space ship tragedies.

  • Native vs Bluebird vs Core-Promise Benchmark

    I just took for a test the native promises implementation (that is available since node v0.12), the bluebird implementation, and core-promise, my own TypeScript implementation.

    The tests are here for the native, bluebirdor core-promise. Note that all the implementations pass the full Promises/A+ test spectrum of 872 tests.

    I ran each test file 11 times, using:

    1
    for f in `seq 0 10`; do time mocha test-core-promise.js > /dev/null 2>&1; done

    Obviously, I changed the file name between iterations.

    I removed 11.9 seconds, because these are setTimeouts in the actual tests, remaining with actual execution of promises time, and these are the final results (in seconds):

     

    Native Bluebird Core-Promise

    1.616 1.760 1.564

    1.567 1.626 1.520

    1.568 1.669 1.548

    1.539 1.657 1.573

    1.574 1.595 1.557

    1.583 1.604 1.580

    1.543 1.582 1.540

    1.529 1.622 1.567

    1.600 1.605 1.567

    1.407 1.661 1.544

    1.467 1.640 1.587

     

    Conclusion

    Unsurprisingly the native implementation won performance wise, but only less than 1% compared to the core-promise, but ~5% compared to bluebird. Also core-promise defaults to the native promises implementation if it's available, if you would use the exported Promise class (for tests I accessed the CorePromise implementation on purpose).

    1
    var Promise = require("core-promise").Promise;

    Not to mention readability of code: core-promise's Promise vs bluebird's Promise.

    *Disclaimer* I am the creator of the core-promise, and yes I feel pretty good getting better performance than the "unmatched performance" of bluebird. :)

Germanium

The one to rule them all. The browsers that is.

SharpKnight

SharpKnight is an Android chess game.

MagicGroup

MagicGroup is an eclipse plugin.