Error.cause could be any?

[conartist6]

lib Update Request

Configuration Check

My compilation target is ES2015 and my lib is the default.

Missing / Incorrect Definition

I'm reporting this issue by request of @ljharb.

Error.cause is typed as Error | undefined but could contain any value. For what it's worth, I can definitely see the appeal of restricting it to the kind of value we hope it contains, but I would like to hear how the maintainers feel about the trade-off.

Personally I think it's a pretty nuanced trade off, and I can imagine a few possible types:

• null | undefined | Error (avoids the risk of null pointers at least)
• unknown (makes some extra work handling causes, but I'm hoping most users will do that once in library code anyway rather than scatter the logic around their apps. Ultimately the language itself should offer the facilities to print causal chains of errors, though that will only be possible once some other proposals land, notably error.stack.
• any (the general type for throwables, also used in AggregateError)

Sample Code

try {
  maybeFail();
} catch (e: any) {
  if (e instanceof Error && e.cause) {
    // cause could still technically be anything at all
    // for example in code written with vError it is a function
    console.log(`Caused by: ${e.cause.name}`)
  }
}

Documentation Link

DefinitelyTyped/DefinitelyTyped#59354 (comment)

[ljharb]

Error causes were designed very carefully to be either absent, undefined (which is different), or any other value - null, an array, a string, etc. the type of cause thus can only be unknown and optional.

[MartinJohns]

Duplicate of #48098.