Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error with cause by default for v4 #4416

Closed
dubzzz opened this issue Nov 8, 2023 · 1 comment
Closed

Error with cause by default for v4 #4416

dubzzz opened this issue Nov 8, 2023 · 1 comment

Comments

@dubzzz
Copy link
Owner

dubzzz commented Nov 8, 2023

Check node, jest, vitest, mocha, jasmine... for support to drop or not the legacy code or just part of it.

@dubzzz
Copy link
Owner Author

dubzzz commented Nov 24, 2023

Node support: ≥16.14 (8th February 2022)

🟢 16.14.0 / 16.14.2 / 16.15.1 / 16.20.2 / 18.0.0 / 18.18.2 / 20.10.0
🔴 12.22.12 / 14.21.3 / 16.0.0 / 16.10.0 / 16.13.2

Code snippet
function g() {
  throw new Error("g failed");
}

function f() {
  try {
    g();
  } catch (err) {
    throw new Error("f failed", { cause: err });
  }
}

f();

🔴 Ava support: no support on 5.3.1
🟢 Jasmine support: ≥4.0.0 (1st January 2022)
🟢 Jest support: ≥29.0.0 (25th April 2022)
🔴 Mocha support: no support on 10.2.0
🟢 Vitest support: ≥0.11.0 (5th July 2022)

Code snippet
function g() {
  throw new Error("g failed");
}

function f() {
  try {
    g();
  } catch (err) {
    throw new Error("f failed", { cause: err });
  }
}

describe("describe", () => {
  it("it", () => {
    f();
  });
});

dubzzz added a commit that referenced this issue Nov 24, 2023
**💥 Breaking change**

Up-to-now fast-check was always sealing the stack attached to errors as they popped. With error with cause capabilities we started to draft the required links to pass the instance of Error up to the end. We can thus safely delay the computation of the stack.

As delaying might have unwanted side-effects (maybe our instance of Error would be touched), we prefer not to make this change as part of a minor release.

Over all the breaking is justified by the change we do on the API of the failures. We dropped the previously precomputed errors and only keep the raw instance of errors. Users now have to manipulate it to extract the relevant error if needed.

First piece for #4416
dubzzz added a commit that referenced this issue Nov 27, 2023
**💥 Breaking change**

Up-to-now fast-check was always sealing the stack attached to errors as they popped. With error with cause capabilities we started to draft the required links to pass the instance of Error up to the end. We can thus safely delay the computation of the stack.

As delaying might have unwanted side-effects (maybe our instance of Error would be touched), we prefer not to make this change as part of a minor release.

Over all the breaking is justified by the change we do on the API of the failures. We dropped the previously precomputed errors and only keep the raw instance of errors. Users now have to manipulate it to extract the relevant error if needed.

First piece for #4416
@dubzzz dubzzz closed this as completed Nov 28, 2023
dubzzz added a commit that referenced this issue Nov 28, 2023
**💥 Breaking change**

Until now, fast-check have been merging the content and stack of the original Error that caused the property to fail into its own Error. With the recent (2022) introduction of cause on Errors, this complex logic can be dropped in favor of the native cause mechanism.

This PR makes cause mode the default. Before this PR, toggling it was possible via `errorWithCause: true` on `fc.assert`.

Given not all test runners properly support causes attached to the Error, we offer a fallback for users willing to preserve the old behaviour. It can be toggled via `includeErrorInReport: true` on `fc.assert`.

Related to #4416.
dubzzz added a commit that referenced this issue Jan 2, 2024
**💥 Breaking change**

Up-to-now fast-check was always sealing the stack attached to errors as they popped. With error with cause capabilities we started to draft the required links to pass the instance of Error up to the end. We can thus safely delay the computation of the stack.

As delaying might have unwanted side-effects (maybe our instance of Error would be touched), we prefer not to make this change as part of a minor release.

Over all the breaking is justified by the change we do on the API of the failures. We dropped the previously precomputed errors and only keep the raw instance of errors. Users now have to manipulate it to extract the relevant error if needed.

First piece for #4416
dubzzz added a commit that referenced this issue Jan 2, 2024
**💥 Breaking change**

Until now, fast-check have been merging the content and stack of the original Error that caused the property to fail into its own Error. With the recent (2022) introduction of cause on Errors, this complex logic can be dropped in favor of the native cause mechanism.

This PR makes cause mode the default. Before this PR, toggling it was possible via `errorWithCause: true` on `fc.assert`.

Given not all test runners properly support causes attached to the Error, we offer a fallback for users willing to preserve the old behaviour. It can be toggled via `includeErrorInReport: true` on `fc.assert`.

Related to #4416.
dubzzz added a commit that referenced this issue May 16, 2024
**💥 Breaking change**

Up-to-now fast-check was always sealing the stack attached to errors as they popped. With error with cause capabilities we started to draft the required links to pass the instance of Error up to the end. We can thus safely delay the computation of the stack.

As delaying might have unwanted side-effects (maybe our instance of Error would be touched), we prefer not to make this change as part of a minor release.

Over all the breaking is justified by the change we do on the API of the failures. We dropped the previously precomputed errors and only keep the raw instance of errors. Users now have to manipulate it to extract the relevant error if needed.

First piece for #4416
dubzzz added a commit that referenced this issue May 16, 2024
**💥 Breaking change**

Until now, fast-check have been merging the content and stack of the original Error that caused the property to fail into its own Error. With the recent (2022) introduction of cause on Errors, this complex logic can be dropped in favor of the native cause mechanism.

This PR makes cause mode the default. Before this PR, toggling it was possible via `errorWithCause: true` on `fc.assert`.

Given not all test runners properly support causes attached to the Error, we offer a fallback for users willing to preserve the old behaviour. It can be toggled via `includeErrorInReport: true` on `fc.assert`.

Related to #4416.
dubzzz added a commit that referenced this issue May 17, 2024
**💥 Breaking change**

Up-to-now fast-check was always sealing the stack attached to errors as they popped. With error with cause capabilities we started to draft the required links to pass the instance of Error up to the end. We can thus safely delay the computation of the stack.

As delaying might have unwanted side-effects (maybe our instance of Error would be touched), we prefer not to make this change as part of a minor release.

Over all the breaking is justified by the change we do on the API of the failures. We dropped the previously precomputed errors and only keep the raw instance of errors. Users now have to manipulate it to extract the relevant error if needed.

First piece for #4416
dubzzz added a commit that referenced this issue May 17, 2024
**💥 Breaking change**

Until now, fast-check have been merging the content and stack of the original Error that caused the property to fail into its own Error. With the recent (2022) introduction of cause on Errors, this complex logic can be dropped in favor of the native cause mechanism.

This PR makes cause mode the default. Before this PR, toggling it was possible via `errorWithCause: true` on `fc.assert`.

Given not all test runners properly support causes attached to the Error, we offer a fallback for users willing to preserve the old behaviour. It can be toggled via `includeErrorInReport: true` on `fc.assert`.

Related to #4416.
dubzzz added a commit that referenced this issue May 29, 2024
**💥 Breaking change**

Up-to-now fast-check was always sealing the stack attached to errors as they popped. With error with cause capabilities we started to draft the required links to pass the instance of Error up to the end. We can thus safely delay the computation of the stack.

As delaying might have unwanted side-effects (maybe our instance of Error would be touched), we prefer not to make this change as part of a minor release.

Over all the breaking is justified by the change we do on the API of the failures. We dropped the previously precomputed errors and only keep the raw instance of errors. Users now have to manipulate it to extract the relevant error if needed.

First piece for #4416
dubzzz added a commit that referenced this issue May 29, 2024
**💥 Breaking change**

Until now, fast-check have been merging the content and stack of the original Error that caused the property to fail into its own Error. With the recent (2022) introduction of cause on Errors, this complex logic can be dropped in favor of the native cause mechanism.

This PR makes cause mode the default. Before this PR, toggling it was possible via `errorWithCause: true` on `fc.assert`.

Given not all test runners properly support causes attached to the Error, we offer a fallback for users willing to preserve the old behaviour. It can be toggled via `includeErrorInReport: true` on `fc.assert`.

Related to #4416.
dubzzz added a commit that referenced this issue Jul 16, 2024
**💥 Breaking change**

Up-to-now fast-check was always sealing the stack attached to errors as they popped. With error with cause capabilities we started to draft the required links to pass the instance of Error up to the end. We can thus safely delay the computation of the stack.

As delaying might have unwanted side-effects (maybe our instance of Error would be touched), we prefer not to make this change as part of a minor release.

Over all the breaking is justified by the change we do on the API of the failures. We dropped the previously precomputed errors and only keep the raw instance of errors. Users now have to manipulate it to extract the relevant error if needed.

First piece for #4416
dubzzz added a commit that referenced this issue Jul 16, 2024
**💥 Breaking change**

Until now, fast-check have been merging the content and stack of the original Error that caused the property to fail into its own Error. With the recent (2022) introduction of cause on Errors, this complex logic can be dropped in favor of the native cause mechanism.

This PR makes cause mode the default. Before this PR, toggling it was possible via `errorWithCause: true` on `fc.assert`.

Given not all test runners properly support causes attached to the Error, we offer a fallback for users willing to preserve the old behaviour. It can be toggled via `includeErrorInReport: true` on `fc.assert`.

Related to #4416.
dubzzz added a commit that referenced this issue Aug 13, 2024
**💥 Breaking change**

Up-to-now fast-check was always sealing the stack attached to errors as they popped. With error with cause capabilities we started to draft the required links to pass the instance of Error up to the end. We can thus safely delay the computation of the stack.

As delaying might have unwanted side-effects (maybe our instance of Error would be touched), we prefer not to make this change as part of a minor release.

Over all the breaking is justified by the change we do on the API of the failures. We dropped the previously precomputed errors and only keep the raw instance of errors. Users now have to manipulate it to extract the relevant error if needed.

First piece for #4416
dubzzz added a commit that referenced this issue Aug 13, 2024
**💥 Breaking change**

Until now, fast-check have been merging the content and stack of the original Error that caused the property to fail into its own Error. With the recent (2022) introduction of cause on Errors, this complex logic can be dropped in favor of the native cause mechanism.

This PR makes cause mode the default. Before this PR, toggling it was possible via `errorWithCause: true` on `fc.assert`.

Given not all test runners properly support causes attached to the Error, we offer a fallback for users willing to preserve the old behaviour. It can be toggled via `includeErrorInReport: true` on `fc.assert`.

Related to #4416.
dubzzz added a commit that referenced this issue Sep 23, 2024
**💥 Breaking change**

Up-to-now fast-check was always sealing the stack attached to errors as they popped. With error with cause capabilities we started to draft the required links to pass the instance of Error up to the end. We can thus safely delay the computation of the stack.

As delaying might have unwanted side-effects (maybe our instance of Error would be touched), we prefer not to make this change as part of a minor release.

Over all the breaking is justified by the change we do on the API of the failures. We dropped the previously precomputed errors and only keep the raw instance of errors. Users now have to manipulate it to extract the relevant error if needed.

First piece for #4416
dubzzz added a commit that referenced this issue Sep 23, 2024
**💥 Breaking change**

Until now, fast-check have been merging the content and stack of the original Error that caused the property to fail into its own Error. With the recent (2022) introduction of cause on Errors, this complex logic can be dropped in favor of the native cause mechanism.

This PR makes cause mode the default. Before this PR, toggling it was possible via `errorWithCause: true` on `fc.assert`.

Given not all test runners properly support causes attached to the Error, we offer a fallback for users willing to preserve the old behaviour. It can be toggled via `includeErrorInReport: true` on `fc.assert`.

Related to #4416.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant