feat(assert): add options parameter to AssertionError constructor

[jsejcksn]

Ref:

• to-do: review custom error classes #5476 (comment)

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 96.48%. Comparing base (72e2462) to head (554ba09).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #5561   +/-   ##
=======================================
  Coverage   96.48%   96.48%           
=======================================
  Files         465      465           
  Lines       37772    37772           
  Branches     5580     5580           
=======================================
  Hits        36445    36445           
  Misses       1285     1285           
  Partials       42       42           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[iuioiua]

Are you able to add a test the ensures that the cause correctly propagates? Also, can you please add an example showing this behavior?

[jsejcksn]

@iuioiua

Are you able to add a test the ensures that the cause correctly propagates?

I didn't see a test module for this class, but I'm happy to create one. I'll add an equality test for the error message property parameter as well.

Also, can you please add an example showing this behavior?

I'm not sure what you have in mind. Do you essentially want me to copy the body of the test? If not, can you make a suggestion?

[jsejcksn]

@iuioiua I added tests using actual control flow. As a contrived but simpler alternative, it could look like this:

Deno.test("AssertionError", () => {
  const originalError = new Error("foo");
  const assertionError = new AssertionError("bar", { cause: originalError });
  assertStrictEquals(assertionError.message, "bar");
  assertStrictEquals(assertionError.cause, originalError);
});

…but that doesn't represent intended usage in exception-handling control flow. With that juxtaposition available, what are your current thoughts about the following?

1. the structure/style of the tests
2. the content of the example documentation

[jsejcksn]

Aside: I'm seeing ci failures in the lint steps (example). They are for the rule no-unreachable, and I think they shouldn't be happening (the tests prove that the lint diagnostic is wrong). Perhaps a new issue should be raised in that repository…

[iuioiua]

I've cleaned up the example and test (they don't have to be too thorough, as this error is used to a large extend throughout testing in the codebase). Now, LGTM! Thanks!

[jsejcksn]

they don't have to be too thorough

@iuioiua Ok, sounds good. I did make one more change: using strict equality comparison for the error.cause because I think it's important to illustrate that they aren't just the same shapes, but actually the same value.

Do you have any thoughts about #5561 (comment)?

[iuioiua]

29bb954

Yes please.

[jsejcksn]

29bb954

Yes please.

Ref:

• false positive: no-unreachable inside catch block when throwing value created outside scope of try deno_lint#1303