es-shims/error-cause

An ES-spec-compliant shim/polyfill/replacement for the `.cause` property on all Error types that works as far down as ES3

error-cause

An ES-spec-compliant shim/polyfill/replacement for the .cause property on all Error types that works as far down as ES3

This package implements the es-shim API “multi” interface. It works in an ES3-supported environment and complies with the proposed spec.

Getting started

npm install --save error-cause

Usage/Examples

const assert = require('assert');

require('error-cause/auto');

try {
		x();
} catch (e) {
		const actual = new Error('a better message!', { cause: e });
		assert(actual instanceof Error);
		assert(actual.cause === e);
}

Tests

Clone the repo, npm install, and run npm test

error-cause's Issues

Action Required: Fix Renovate Configuration

There is an error with this repository's Renovate configuration that needs to be fixed. As a precaution, Renovate will stop PRs until it is resolved.

Error type: Cannot find preset's package (github>whitesource/merge-confidence:beta)

Do not promote non-`Error` causes in README

const e = new Error('message!', { cause: 'bugs' });

assert(e instanceof Error);
assert(e.cause === 'bugs');

As discussed eg here tc39/proposal-error-cause#21 the main intended purpose is to wrap/chain caught errors, so in at least 80% of the cases the cause will likely be an Error, at least from the intent of the spec.

Having an example that hints that causes are mainly/only intended to be strings adds needless confusion.

I would propose an example similar to mine here: https://github.com/voxpelli/pony-cause#errorwithcause-creating-an-error-with-a-cause

By sending in a caught exception one avoids confusing people about what exactly the type sent in is supposed to be and instead shows that it’s supposed to be whatever a catch can catch.

Typescript types

There are no types, so constructing an error this way in a project with types is still a type error. The needed type is:

interface Error {
  new (reason: string, options?: { cause?: unknown }): Error;

  cause: unknown;
}

Are there any existing examples of how to handle types correctly for both pure (const { Error } = require('error-cause')) and impure (require('error-cause/auto')) usages?

Dependency Dashboard

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Pending Approval

These branches will be created by Renovate only once you click their checkbox below.

• [Deps] Update Update eslint to v8.57.0
• [Deps] Update Update eslint to v9
• [Deps] Update Update nyc to v15
• 🔐 Create all pending approval PRs at once 🔐

Detected dependencies

github-actions

.github/workflows/node-aught.yml

.github/workflows/node-pretest.yml

.github/workflows/node-tens.yml

.github/workflows/rebase.yml

.github/workflows/require-allow-edits.yml

npm

package.json

• call-bind ^1.0.7
• define-properties ^1.2.1
• es-abstract ^1.23.3
• es-aggregate-error ^1.0.13
• es-errors ^1.3.0
• globalthis ^1.0.3
• has-property-descriptors ^1.0.2
• @es-shims/api ^2.5.0
• @ljharb/eslint-config ^21.1.0
• aud ^2.0.4
• auto-changelog ^2.4.0
• eslint =8.8.0
• evalmd ^0.0.19
• function.prototype.name ^1.1.6
• has-strict-mode ^1.0.1
• in-publish ^2.0.1
• npmignore ^0.3.1
• nyc ^10.3.2
• safe-publish-latest ^2.0.0
• tape ^5.7.5
• node >= 0.4

---

• Check this box to trigger a request for Renovate to run again on this repository

Overwrites constructor

Currently the error implementation overwrites constructor, destroying any value that may already be in it.

error-cause/Error/implementation.js

Line 15 in 463e17f

O.constructor = Error;

This creates problems down the road, since errors usually need to know their constructor as they use it to eliminate stack frames including and above their constructor in the stack trace. The current implementation makes that impossible.