Skip to content

TC39 proposal - Error.cause property #45167

Description

@sirian

lib.es2021d.ts Update Request - Error.cause property

Proposal (Stage 3)
https://github.com/tc39/proposal-error-cause

Already implemented in Chrome 93:
https://www.chromestatus.com/feature/5727099325251584

Sample Code

interface Error {
    cause?: any;
}

interface ErrorInit {
    cause?: any;
}

interface ErrorConstructor {
    new(message?: string, init?: ErrorInit): Error;
    (message?: string, init?: ErrorInit): Error;
}

Activity

  1. johanneswuerbach commented on Sep 7, 2021

    @johanneswuerbach

    Error.cause is also available in Node 16.9.0 now 🎉

  2. majg0 commented on Oct 27, 2021

    @majg0

    Bump

  3. Alexsey commented on Nov 4, 2021

    @Alexsey

    Already Stage 4 - the feature is finalized!

  4. sandersn commented on Nov 5, 2021

    @sandersn
    Member

    Fixed by #46291 (and #45749, but I missed reviewing that one.)

  5. amakhrov commented on Dec 14, 2021

    @amakhrov

    This seems to be partially implemented.

    The constructor now accepts ErrorOptions with the cause property - which is great.
    However, this property is not declared in the Error object itself.

    With the full implementation this example should compile:

    const error = new Error("derived", {cause: new Error("original")}); // OK
    console.log(error.cause); // Property 'cause' doesn't exist
    

    Nathan Shively-Sanders (@sandersn)

  6. sandersn commented on Dec 16, 2021

    @sandersn
    Member

    Thanks for pointing that out. I re-opened the bug.

  7. GoudekettingRM commented on Feb 9, 2022

    @GoudekettingRM

    Bump. Also ran into this. Fixed it local by redeclaring like this:

    interface Error {
      name: string;
      message: string;
      cause?: any;
      stack?: string;
    }
    
    interface ErrorConstructor {
      new(message?: string, { cause }?: { cause: any }): Error;
      (message?: string): Error;
      readonly prototype: Error;
    }
    
    declare var Error: ErrorConstructor
  8. mcaskill commented on Feb 9, 2022

    @mcaskill

    I also had this issue for cause and stack. Fixed it by redeclaring like this:

    interface ErrorInit {
        cause?: unknown;
    }
    
    declare type BaseError = Error;
    
    declare class Error implements BaseError {
        name: string;
        message: string;
        stack?: string;
        cause?: unknown;
    
        constructor(message?: string, init?: ErrorInit);
    
        // eslint-disable-next-line @typescript-eslint/ban-types -- Allow catch-all 'function' parameter type.
        static captureStackTrace(error: object, constructor?: Function): void;
    }
  9. yume-chan commented on Mar 18, 2022

    @yume-chan
    Contributor

    cause was added in #47020 and all definitions had shipped with 4.6.

  10. MartinJohns commented on Mar 19, 2022

    @MartinJohns
    Contributor

    Simon Chan (@yume-chan) Although the type is inaccurate, as per #48098.

  11. locked as resolved and limited conversation to collaborators on Oct 21, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    BugA bug in TypeScriptDomain: lib.d.tsThe issue relates to the different libraries shipped with TypeScriptES NextNew featurers for ECMAScript (a.k.a. ESNext)Help WantedYou can do this

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions