suggestion: internal `assertStrictThrows()` and `assertStrictRejects()` about deno_std

[kt3k]

I don't think we need this. assertThrows returns the thrown error. We can assert whatever thing on it by using it. That pattern is more flexible than assertStrictThrows as we can assert about any property (like .code for DOMException or Node compat errors).

const err = assertThrows(() => someFunc());

assertEquals(err.message, "The error message");
assertEquals(err.code, "ERR_FOO_BAR");

[iuioiua]

I don't think we need this. assertThrows returns the thrown error. We can assert whatever thing on it by using it. That pattern is more flexible than assertStrictThrows as we can assert about any property (like .code for DOMException or Node compat errors).

const err = assertThrows(() => someFunc());

assertEquals(err.message, "The error message");
assertEquals(err.code, "ERR_FOO_BAR");

That's easily fixed by returning the error at the end of these assertions.

The main issue these functions aim to fix is fully defining error properties in tests. This is because arguments are optional, and we only check that a message includes a string instead of equalling a string. Once test assertions are updated across the codebase, these functions ensure we check thrown/rejected errors strictly. Otherwise, parts of errors can fly under the radar within tests. I came up with this, but I'm happy to hear other solutions.

[kt3k]

That's easily fixed by returning the error at the end of these assertions.

I don't understand this. assertThrows currently returns the error object. assertRejects returns the promise of the error. If the user prefer to check the equality of the message, then the above example is what is recommended now. ref #2220 #2226

[iuioiua]

We discussed this offline. Instead, we can create design documentation and then a tracking issue to adjust the codebase to that new convention.