Promise.catch null vs null as null

Bug Report

🔎 Search Terms

🕗 Version & Regression Information

This is a crash
This changed between versions ______ and _______
This is the behavior in every version I tried, and I reviewed the FAQ for entries about _________
I was unable to test this on prior versions because _______

⏯ Playground Link

💻 Code

Version 4.4.0-dev.20210705

export function f1()
{
	return Promise.resolve(1).catch(e => null)
}

export function f2()
{
	return Promise.resolve(1).catch(e => null as null)
}

// @ts-expect-error
f1().then(v => v.split('')) // <====== should is `number` but `any`

// @ts-expect-error
f2().then(v => v.split(''))

{
  "compilerOptions": {
    "module": "commonjs",
    "target": "es2019",
    "jsx": "preserve",
    "moduleResolution": "node",
    "allowJs": false,
    "allowUmdGlobalAccess": false,
    "sourceMap": true,
    "inlineSourceMap": false,
    "inlineSources": true,
    "declaration": true,
    "experimentalDecorators": true,
    "emitDecoratorMetadata": true,
    "allowSyntheticDefaultImports": true,
    "resolveJsonModule": true,
    "strict": false,
    "strictBindCallApply": true,
    "strictNullChecks": false,
    "strictFunctionTypes": true,
    "noImplicitThis": true,
    "noImplicitOverride": true,
    "preserveConstEnums": true,
    "forceConsistentCasingInFileNames": true,
    "incremental": true,
    "noErrorTruncation": true,
    "removeComments": true,
    "traceResolution": false,
    "newLine": "lf",
    "esModuleInterop": true,
    "importHelpers": true
  }
}

🙁 Actual behavior

// @ts-expect-error
f1().then(v => v.split('')) // <====== should is `number` but `any`

🙂 Expected behavior

// @ts-expect-error
f1().then(v => v.split('')) // <====== should is `number`

I think this happens because in the absence of a type annotation, null gets inferred as any, even under strictNullChecks.

let x = null;  // type: any
let y = null as null;  // type: null

I think this happens because in the absence of a type annotation, null gets inferred as any, even under strictNullChecks.
let x = null;  // type: any
let y = null as null;  // type: null

That's not quite true. When outside of --strictNullChecks there are two null types: A non-widening null type and a widening null type. The widening null type is returned when null is used as an expression, while the non-widening null type is returned when null is used as a type. At any point where we widen (such as when we widen "foo" to string), the widening null is either removed from any union it is contained in, or is converted to any, while the non-widening null is only removed from unions if there are any other non-widening types. When inside of --strictNullChecks, there is only ever one null type, which is the non-widening null type. The same is also true for undefined.

The example you show here isn't quite correct, as the type you see when you hover over x isn't the inferred type, it is the type resulting from control flow analysis:

// @strictNullChecks: true
let x = null;
//  ^?  let x: any

   x;
// ^?   let x: null

Playground

In the example from the OP, you can see that both number and null are preserved in --strictNullChecks:

// @strictNullChecks: true
export function f1()
{
	return Promise.resolve(1).catch(e => null)
}

export function f2()
{
	return Promise.resolve(1).catch(e => null as null)
}

// @ts-expect-error
f1().then(v => v.split('')) // <====== should is `number` but `any`
//        ^? (parameter) v: number | null

// @ts-expect-error
f2().then(v => v.split(''))
//        ^? (parameter) v: number | null

Playground

The reason why you see any is due to null being the only possible return value of .catch. As a result, it widens to any as the type escapes the body. You can see that here, though I had to replace the arrow functions with function expressions so I could have something to point the ^? comment at:

// @strictNullChecks: false
export function f1()
{
	return Promise.resolve(1).catch(function(e) { return null; })
        //                              ^? (local function) (e: any): any
}

export function f2()
{
	return Promise.resolve(1).catch(function (e) { return null as null; })
        //                              ^? (local function) (e: any): null
}

// @ts-expect-error
f1().then(v => v.split('')) // <====== should is `number` but `any`
//        ^? (parameter) v: any

// @ts-expect-error
f2().then(v => v.split(''))
//        ^? (parameter) v: number

Playground

As a result, when constructing the resulting Promise type returned from catch in f1, the result is number | any, which is reduced to any.

Currently, this is a limitation of running outside of --strictNullChecks, but I'm considering whether there are any changes we can make here.

I've put up #59661, which reports an error due to the implicit widening from null to any.

Navigation Menu

Repository navigation

Promise.catch `null` vs `null as null` #44913

Bug Report

🔎 Search Terms

🕗 Version & Regression Information

⏯ Playground Link

💻 Code

🙁 Actual behavior

🙂 Expected behavior

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Promise.catch null vs null as null #44913

Description

Bug Report

🔎 Search Terms

🕗 Version & Regression Information

⏯ Playground Link

💻 Code

🙁 Actual behavior

🙂 Expected behavior

Activity

fatcerberus commented on Jul 8, 2021

rbuckton commented on Oct 23, 2023

rbuckton commented on Aug 16, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Promise.catch `null` vs `null as null` #44913