gs.getProperty() - my "habits"

[Andy-L]

Personally, there are a couple of things I don’t like about gs.getProperty() ....

The ServiceNow GlideSystem method gs.getProperty() is a frequently used function to store configurations outside of the code. This is ServiceNow best practice.

It returns null if the property doesn’t exist (or you can specify a default value).  So what don't I like and why? I think it encourages the following issues, particularly for larger codebases ...

1. Often, a property might actually be mandatory, but the code does not check for its existence, and the hope is that the 'null' value will somehow get caught by some later bit of code before too much harm has been done.
2. It encourages the design of 'optional' properties. As they are optional :
   - they must be documented outside of the delivered implementation, otherwise they can become lost, invisible and almost 'secret' knowledge.
   - they create an additional code path to be tested (set vs unset)

I tend to code quite defensively by default, so I will usually throw an error if a property doesn't exist. This helps to ensure the property is kept with the code base, is self-documenting, and it's less likely to get omitted during a migration, etc.

var someValue = gs.getProperty('somePropertyName');  

if (someValue === null) {
       throw new Error(‘Property does not exist: somePropertyName’); 
}

Usually, I write a small function, e.g. getProp(), at the application level. I avoid calling it getProprerty() so it doesn't get confused with the original gs.getProperty() function. 

/**
 * Get a property throw an exception if it doesnt exist.
 *  {string} propName - the property Name
 * @returns {string} the property value
 */
function getProp(propName) {

   var propVal = gs.getProperty(propName);

   if (propVal === null) {
       throw new Error('Property does not exist: '+propName);
    }
    return propVal;
}

var someValue = getProp('somePropertyName');

I usually add the option to pass through the default value too - so it's a drop-in replacement:

/**
 * Get a property throw an exception if it doesnt exist.
 *  {string} propName - the property Name
 *  {string} defaultVal - a default value
 * @returns {string} the property value
 */
function getProp(propName,defaultVal) {

   var propVal = gs.getProperty(propName,defaultVal);

   if (defaultVal === undefined && propVal === null) {
       throw new Error('Property does not exist: '+propName);
    }
    return propVal;
}

I've written this up here and might add some more thoughts later.

[Ravi Gaurav]

Hi @Andy-L 

This is a great observation and I agree with your thinking.

Here’s how you could structure a clear, community-style answer / article out of what you’ve written, while keeping the critique + solution balanced:

Why I Don’t Like Relying Solely on gs.getProperty()

The gs.getProperty() method is one of the most commonly used GlideSystem functions in ServiceNow. It’s often seen as a best practice for keeping configuration outside of code.

👉 But in my experience, it also comes with hidden problems when used without discipline — especially in larger codebases.

 

The Issues with gs.getProperty()

1. Encourages “Optional” Properties

   • By default, if a property doesn’t exist, it just returns null.

   • This makes it easy to ignore missing properties and hope that some later piece of logic catches the problem.

2. Hidden Knowledge

   • If a property is truly required but isn’t documented or packaged with the implementation, it becomes “secret knowledge.”

   • Developers or admins migrating code to another instance can easily miss it.

3. Extra Code Paths

   • An unset property creates an extra path to test (set vs unset).

   • That’s unnecessary complexity if the property should never be unset in the first place.

[Andy-L]

Thanks @Ravi Gaurav , for the response and the perspective. I think the bullet points generated changed the original meaning slightly - I've reworked below:

The Issues with gs.getProperty()

• Mandatory properties are not enforced
  • By default, if a property doesn’t exist, it just returns null, and the script continues running. This makes it harder to detect missing properties, as the null value may silently propagate, resulting in more unpredictable and severe errors.
• Encourages “Optional” Properties / Hidden Knowledge
  • If a property is optional but isn’t documented outside the system or packaged with the implementation, it becomes “secret knowledge” that is only found when inspecting the code.
  • Developers or admins migrating code to another instance can easily miss it.
• Extra Code Paths
  • An unset property creates an extra path to test (set vs unset). This adds unnecessary complexity, particularly if the property should indeed be mandatory.

Cheers,
Andy