In TypeScript, no errors are thrown when accessing a property of an undefined object

Question

In TypeScript, no errors are thrown when accessing a property of an undefined object

const testResult = config.layers?.find((layer) => layer.id === 'blah')?.dataSource!;
console.log('testResult: ', testResult);

I have an object named Configuration (referred to as "config"), which contains an array of Layers.

Each layer is assigned an "id".

Despite not having an id labeled "blah", why does the output show testResult: undefined?

I would have anticipated a runtime error instead.

As far as I know, the "!" symbol indicates that the variable cannot be undefined. However, the .find() method returned an undefined object, making ".dataSource" inaccessible.

This situation has left me baffled!

Could there be a configuration setting causing this unexpected behavior?

Below is my tsconfig.json file:

{
    "extends": [
        "eslint:recommended",
        "google",
        "react-app",
        "plugin:jsx-a11y/recommended",
        "plugin:react/recommended",
        "plugin:react/jsx-runtime",
        "plugin:@typescript-eslint/eslint-recommended",
        "plugin:@typescript-eslint/recommended",
        "plugin:@typescript-eslint/recommended-requiring-type-checking",
        "plugin:prettier/recommended",
        "plugin:jest/recommended"
    ],
    "parser": "@typescript-eslint/parser",
    "parserOptions": {
        "ecmaFeatures": {
            "jsx": true
        },
        "ecmaVersion": "2018",
        "sourceType": "module",
        "project": ["tsconfig.test.json"]
    },
    "plugins": ["react", "jsx-a11y", "@typescript-eslint", "prettier", "jest"],
    "rules": {
        "@typescript-eslint/no-unused-vars": "error",
        "@typescript-eslint/no-explicit-any": "error",
        "@typescript-eslint/no-empty-interface": "off",
        "require-jsdoc": [
            "error",
            {
                "require": {
                    "FunctionDeclaration": false,
                    "MethodDefinition": false,
                    "ClassDeclaration": false,
                    "ArrowFunctionExpression": false,
                    "FunctionExpression": false
                }
            }
        ],
        "jest/no-disabled-tests": "warn",
        "jest/no-focused-tests": "error",
        "jest/no-identical-title": "error",
        "jest/prefer-to-have-length": "warn",
        "jest/valid-expect": "error"
    }
}

typescript

Answer 1

Answer №1

Your mistake is not related to TypeScript typing, but rather standard JavaScript behavior.

By using optional chaining, you instruct JavaScript to verify the value on the left of the chain. If it is null or undefined, the operation on the right will be bypassed. Consider the following example:

const foo = {
  a: 'abc',
  b: null,
};

console.log(foo.b.length);
console.log(foo.b?.length);

The first console log will result in an error because accessing `length` on a null value like `foo.b` is not allowed. However, the second log will output "null" since `b?.length` means "Access `length` only if `b` is not null, otherwise return null."

Therefore, in this code snippet:

config.layers?.find(...)?.dataSource!

You are assuming that `dataSource` is non-null, despite having optional chaining for both `layers` and `find(...)`. If either of those expressions returns null or undefined, the execution stops at that point, and `dataSource!` is never reached.

If you wish to apply the non-null assertion to the entire line, wrap the entire expression in parentheses:

(config.layers?.find(...)?.dataSource)!

However, at this stage, you should be absolutely certain about your actions as you are essentially disregarding TypeScript's compile-time null safety feature.

Answer 2

Your mistake is not related to TypeScript typing, but rather standard JavaScript behavior.

By using optional chaining, you instruct JavaScript to verify the value on the left of the chain. If it is null or undefined, the operation on the right will be bypassed. Consider the following example:

const foo = {
  a: 'abc',
  b: null,
};

console.log(foo.b.length);
console.log(foo.b?.length);

The first console log will result in an error because accessing `length` on a null value like `foo.b` is not allowed. However, the second log will output "null" since `b?.length` means "Access `length` only if `b` is not null, otherwise return null."

Therefore, in this code snippet:

config.layers?.find(...)?.dataSource!

You are assuming that `dataSource` is non-null, despite having optional chaining for both `layers` and `find(...)`. If either of those expressions returns null or undefined, the execution stops at that point, and `dataSource!` is never reached.

If you wish to apply the non-null assertion to the entire line, wrap the entire expression in parentheses:

(config.layers?.find(...)?.dataSource)!

However, at this stage, you should be absolutely certain about your actions as you are essentially disregarding TypeScript's compile-time null safety feature.

Answer 3

Answer №2

It appears that there is some confusion regarding the purpose of the ! symbol in TypeScript. This symbol instructs the TS language server to disregard any potential for the variable dataSource being undefined.

Furthermore, it seems there may be a misunderstanding about how TypeScript operates - errors will not be thrown because TypeScript ultimately compiles down to plain JavaScript when executed. TypeScript primarily serves to assist in writing more reliable and robust code, without altering the runtime behavior.

When utilizing the ! symbol, you are essentially declaring: "I am certain that dataSource does exist", thereby signaling to the IDE to suppress any related errors. This operator effectively carries out a non-null assertion

However, if it turns out that dataSource is indeed undefined, this could be due to either the variable itself being undefined or the find() method returning nothing.

Answer 4

It appears that there is some confusion regarding the purpose of the ! symbol in TypeScript. This symbol instructs the TS language server to disregard any potential for the variable dataSource being undefined.

Furthermore, it seems there may be a misunderstanding about how TypeScript operates - errors will not be thrown because TypeScript ultimately compiles down to plain JavaScript when executed. TypeScript primarily serves to assist in writing more reliable and robust code, without altering the runtime behavior.

When utilizing the ! symbol, you are essentially declaring: "I am certain that dataSource does exist", thereby signaling to the IDE to suppress any related errors. This operator effectively carries out a non-null assertion

However, if it turns out that dataSource is indeed undefined, this could be due to either the variable itself being undefined or the find() method returning nothing.

Answer 5

Answer №3

The rationale behind this behavior lies in the use of Optional Chaining (?).

const testResult = config.layers?.find((layer) => layer.id === 'blah')?.dataSource!;

If config.layers is undefined, the find method won't be invoked on it, and JavaScript will simply default to testResult, which will be undefined.

This cascades down the chain as well, meaning that if find doesn't return anything, then the dataSource property remains untouched.

Answer 6

The rationale behind this behavior lies in the use of Optional Chaining (?).

const testResult = config.layers?.find((layer) => layer.id === 'blah')?.dataSource!;

If config.layers is undefined, the find method won't be invoked on it, and JavaScript will simply default to testResult, which will be undefined.

This cascades down the chain as well, meaning that if find doesn't return anything, then the dataSource property remains untouched.

In TypeScript, no errors are thrown when accessing a property of an undefined object

Answer №1

Answer №2

Answer №3

Similar questions

What is the term for specifying a variable's data type using a set of values instead of a traditional type?

Converting JSON into TypeScript class or interface?

Type of Multiple TypeScript Variables

Tips for using jest toHaveBeenCalled with multiple instances

Encountering problem with '@datadog/browser-rum' compilation related to the 'allowedTracingOrigins' attribute

What is the method to group a TypeScript array based on a key from an object within the array?

Error: Attempting to access a property called 'sign' on an undefined value

The concept of inheritance in CommonJS using Typescript

Unable to convert JSON response into an array while using Angular 2

Managing data with Angular 2: Setting and retrieving values

Discover the key to ensuring that optional peer dependencies are genuinely optional

Error message: The database query function is encountering an issue where the property 'relation.referencedTable' is undefined and cannot be accessed

Transferring data from the server to the client side in Next JS with the help of getInitialProps

"An issue arises as the variable this.results.rulesFired is not properly

Updating non-data properties dynamically in a custom AG Grid cell renderer

Handling functions in Ant Design Select component with TypeScript types

Error: Unable to access to the 'title' property of a null value

Issues arise as a result of conflicts between the dependencies of @ionic/angular, Angular 13, typescript,

The inferred type of a TypeScript promise resolved incorrectly by using the output value from a callback function

Simplify if statements by eliminating repetition