config.js

/**
 * Module dependencies.
 */

var pkg = require('../package');
var env = process.env.NODE_ENV || 'development';

/**
 * Return setting `name`.
 *
 * @param {String} name
 * @return {Mixed}
 * @api public
 */

module.exports = function(name){
  if (null == pkg[env]) throw new Error('invalid configuration environment "' + env + '"');
  if (null == pkg[env][name]) throw new Error('invalid configuration key "' + name + '"');
  return pkg[env][name];
};

@menzoic, the question of fatality for a missing setting is generally up to the application code to decide, though, and it's shorter/prettier to write:

var configvar = config('configvarname') || 'default_value'; 

than the whole try.. catch.. thing. Epsecially when you'll be doing it all over the code, for every setting. Throwing exceptions in Node is a risky business. While this function is not async, its caller probably will be, so it's not like you can trust traditional bubbling-up of the exceptions along the call stack. Side effects can be ugly.

Regarding your second question, code on line 6 in the original does something different, it says: "if no environment is defined, assume 'development'", which is not the same as what DEFAULT_ENV does.

The need for DEFAULT_ENV stems from the fact that typically settings for various environments are mostly the same, and you only customize some settings for each environment. You wouldn't want to duplicate the common settings in each env config. maybe COMMON_ENV is a more clear, better name, but in my experience, most people call it default settings.

assume production would be safer as far as precedence goes, I've found throwing extremely helpful, little typos in config etc go undetected, it would have to be a pretty massive fail to have that throw in production, so unless you don't write tests or use your app at all it's fine