-
-
Notifications
You must be signed in to change notification settings - Fork 180
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
Comments
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 Code snippetfunction 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 Code snippetfunction 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
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
Check node, jest, vitest, mocha, jasmine... for support to drop or not the legacy code or just part of it.
The text was updated successfully, but these errors were encountered: