ciplogic.com
Live with grace. Write superb software.

firefox

  • 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.

  • What Do We Learn from the Broken Firefox WebDriver Support

    Originally published at the project's site: http://www.germaniumhq.com/2016/07/03/2016-07-03-What-Do-We-Learn-from-the-Broken-Firefox-WebDriver-Support/

    With the new release of Firefox 47, the WebDriver support was left in limbo. On one hand, the old WebDriver API was not accessible anymore, on the other hand the new API (Marionette) explicitly didn’t support it. Kid you not, they actually used the word explicitly when saying they don’t support version 47, despite Mozilla telling on the release notes to use it.

    “Go use it, it’s broken” [probably someone at Mozilla]

    Of course, this lead to the Mozilla team releasing a hotfix for Firefox, namely 47.0.1 which fixed, you guessed it, allowing the old WebDriver API to work. The only small problem is that Mozilla knowingly introduced a bug that nuked all the WebDriver Firefox tests. For 3 weeks. Between June 7 and June 28.

    Unreal.

    Solution

    Now that we know this might happen, how do we mitigate this?

    The answer is containers. Docker containers.

    Germanium, out of the box, comes into two flavours. One one hand it’s the library itself that we know and love and that gets tested against a set of browsers.

    Now, for Firefox and Chrome, also docker images are automatically built, that guarantees such changes in infrastructure aren’t destroying your tests stability. For Firefox, since version 47 wasn’t running anymore using WebDriver, the container used Firefox 46 and the old API (the Marionette support is at this stage abysmal).

    Of course, this means we’re not on the bleedingest of edges of the browser version, but that is OK. In the Continuous Integration system, we want to be sure we don’t get all our tests failing just because WebDriver has a bug now, especially since the API itself it’s still coagulating, so this is bound to happen some more. The key is to lock the moving parts of the testing environment, and Germanium does that by default.

    Also these images themselves are used to test Germanium itself. So you know that all the API calls that are documented there are running as expected.

Germanium

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

SharpKnight

SharpKnight is an Android chess game.

MagicGroup

MagicGroup is an eclipse plugin.