Configuration files are, well… files. File operations are “risky”- there’s a lot of reasons why they might fail, and we have to be prepared to handle those execptions.

For example, maybe you’ve written an application that reads a configuration file at launch. If, for some reason, it failed to load that config, you’d need to deal with that. If the configuration were just some minor settings, you might choose to fallback to some reasonable defaults. If, on the other hand, the configuration contained important security settings, you would probably want to quit the application, or maybe fallback into some “safety” mode.

Patrick U. assumed that was how the NodeJS application he was working on behaved. Then, one of his fellow developers pushed their latest release into production. He went to log into his admin account, and found his password didn’t work- because it had been mysteriously changed to the incredibly insecure “admin”. After a little poking, he found someone had left off a closing-quote in their JavaScript configuration file, and that solved the problem. But why did his password get changed when the config file was broken? Well, this code was responsible for loading the file: 

try {
  settings = require('../Settings');
}
catch (e) {
  settings = {
    users: {
      admin: { password: 'admin', is_admin: true },
      grace: { password: 'admin', is_admin: true },
      patrick: { password: 'admin', is_admin: true },
      bert: { password: 'foobar', is_admin: false }
    }
  };
}
[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!