Jujhar Singh

In the US today we celebrate Thanksgiving, and I really feel thankful that I can be a programmer.

For over 33 years now I've been writing code professionally, never going more than 3 weeks without writing something. It's hard to imagine how many lines I've written.

There is nothing like the creativity, the discipline, the desire to learn, the ability to make something that started with nothing but a blank screen. I was accepted into a PhD program in Chemistry before I decided more school was not for me and got my first job in October of 1981.

Is there any job like this one? Where everything you know changes at an ever-increasing pace, where the challenges of programming never end, and the need to produce quality is a constant reminder. I can't remember a time when I didn't love what I got to do, even when circumstances were terrible, or companies failed out from under me. The jobs weren't always all that great or even stunk but I could always get satisfaction from seeing the code flow. Even living in an area where the work wasn't always easy to find and times were difficult, I always knew that there had to be a place for someone who could write good code even if it took a while to find the right one.

I love playing music and cooking and even writing blog posts but writing code is something special. You get to tell a freaking computer what to do and it does it! Sometimes too literally but still there is a feeling of power, of mastering knowledge, of making something from nothing that only programming can bring.

When I started computers were big and slow and ugly and today they fit in your pocket. Every change, every new technology or language or framework or OS or process or idea was fun to learn and sometimes master. If I didn't like this change I would have left a long time ago, but I still love the challenge of new. Keeping ahead of the technology steamroller (learn or be flattened) keeps getting tougher but I always can't wait to see what happens next. This business is so full of amazing people who keep coming up with stuff you could never imagine just last year. Nothing else is like it.

I had no clue what my career would be like 3 decades later, if I even thought about that then, when I started. Even though virtually everything is new today, the need to produce, to figure it out, to keep the quality high, to maybe even invent something no one else thought about, it's still the same job.

I've been able to work with awesome programmers and average, write award winning programs and stuff no one ever saw. I've seen jobs come and go, sometimes even fail from one minute to the next. Occasionally my work has been featured up on screens in a keynote and sometimes no one even knew what I did. I've written good stuff under enormous pressure when everyone around me was panicky and but also had the leisure to ensure every last thing was perfect. Every kind of program, business, environment, big companies and small, my own two little startups in the 80's and even Apple when it was almost out of business.

Programming is a hard job but it's much easier when you love what you are doing. I can't see it as just a job but a vocation. The moment I stop loving to code is the moment I leave.

For now though I'm just glad I have the chance to do this for a living. To paraphrase Ice Cube, Today Is A Good Day to be a programmer.

It is a crucial part to have an excellent strategy for handling errors in your application. Not just for identifying bugs quickly but also for propagating sane messages to the user in the case when an operation has failed. I guess propagating is the correct term in this context. If you build an application architecture which consists of different layers and orchestrates several third-party modules, you will be confronted with the same question over and over again: How to handle those different errors from the lower layers correctly and make my application more robust?

One pattern that I use in my applications and which is also highly recommended by Joyent (see Error Handling in Node.js) is to wrap error objects instead of just passing them to the callback. A simple passing without augmenting the error can be stated as an anti-pattern. An example:

'use strict';

var fs = require('fs');

exports.readConfig = function readConfig (file, callback) {
  function onRead (err) {
    if (err) {
      //
      // Anti-Pattern alert!
      // Don't just spit the
      // "raw" error object back.
      //
      return callback(err);
    }
  }

  fs.readFile(file, onRead);
};

A much cleaner approach would be to create a new error object and extend it by the thrown message. This is where verror (GitHub: davepacheco/node-verror, License: MIT) by David Pacheco enters the stage. It provides you the functionality for combining several error objects by preserving each one’s message. The result will be a concatenated message that gives you a good clue about the complete function chain. Therefore you will immediately know where something went wrong. Let’s check it out:

npm install verror

The module itself can be seen as a drop-in replacement of the native error object instances.

'use strict';

var fs = require('fs');
var VError = require('verror');

exports.readConfig = function readConfig (file, callback) {
  function onRead (err, content) {
    if (err) {
      return callback(new VError(err, 'failed to read config file "%s"', file));
    }

    try {
      content = JSON.parse(content);
    } catch (e) {
      return callback(new VError(e, 'failed to parse config file "%s"', file));
    }

    callback(null, content);
  }

  fs.readFile(file, onRead);
};

Please not that the module supports printf-style error message construction which is pretty cool. If we execute the above function as

exports.readConfig('/not/available.json', function onRead (err, config) {
  if (err) {
    return console.error(err.message);
  }
  ...
});

it will obviously fail because of the non-existent configuration file. The printed message will then look like:

failed to read config file "/not/available.json": ENOENT, open '/not/available.json'

So if you pass the root cause to the VError constructor, you will be able to receive the complete concatenated error message string. That’s awesome! But what if you only want to see the error message from the highest layer and still be able to access the low-level errors programmatically? verror provides another constructor for cases like that, called WError. It wraps all error objects in the lower levels, but stores the message of the “highest one” in it’s message attribute. If you have to access the other wrapped objects, you get the full details by calling toString() on a WError instance.

To see those both types in action, make sure to check out runnable example and the example repository.

What’s Next?

You have your very own best practices about handling errors in Node.js? I’m curious about those and would be more than happy to read about them in the comments :)

It’s difficult for a 110 pound dog to fit under a bed

[Arbroath]

The post OMG dog under bed appeared first on Say OMG - omg videos,omg photos, omg news, omg images, omg movies on say OMG.