Repository navigation
assert.ok() throwing AssertionError instead of provided Error object #50780
Description
Activity
Lines 396 to 398 in 25fdb48
It clearly re-thrown if the message is instanceof
Error, butinstanceofchecking may not be true depends on testing framework.A minimal repo shown it is working correctly.
import { ok } from 'assert/strict' ok(false, Error('here is error'))
Reacted by Antoine du HamelThis working as expected and will throw to avoid reading a Node.js module, as doing so could potentially result in misleading errors being thrown from module.
instanceofchecking may not be true depends on testing frameworkMy fault... I'm using Jest, and forget it has problems with
instanceofand builtin classes 🤦🏻. Could make it sense to use ducktyping and check forErrorobjects fields? Based on spec,message,nameandstackcan made us pretty sure they areErrorobjects themselves...We could use the same algorithm as
util.isError:Lines 167 to 169 in 1858341
We could use the same algorithm as
util.isErrorIt's deprecated, and also it would not work for
Errorchild classes.The function is deprecated, but not what it does. It works fine with child classes.
It works fine with child classes.
I think it wouldn't, because on child classes, the prototype constructor name would be different of
Errorstring, so the comparison would fail and we would get to thee instanceof Error, leading to the same Jest error we have here in this issue.If you don't believe me, try it
We can also add a check that looks
util.types.isNativeError(). That is howassertitself checks for errors next to instanceof.I like the idea.
Hello, I would like to try and work on this issue.
What do you need?
Seeing the discussion, I will try to implement both the methods mentioned to see if it actually throws the required error. Will update accordingly?
9 remaining items
Hi, can I work on this issue?
Hi, can I work on this issue?
Sure, go for it :-)
is this issue still open ?
Yes, it's still a problem.
I noticed that this issue is stalled even though there is an almost accepted PR that solves the problem.
I addressed the comments and fixed the problem that was blocking the CI (we'll find out on the next CI run, hehe 🐍 ).PR: #53980
P.S.: I added the author of the PR and the commenter as co-authors in the commit.
- added a commit that references this issue
on Jul 28, 2024 Great, good work @pmarchini :-)
Reacted by Pietro Marchini- added a commit that references this issue
on Jul 30, 2024 - added a commit that references this issue
on Aug 5, 2024
Version
v20.9.0
Platform
Linux executive 6.5.0-10-generic #10-Ubuntu SMP PREEMPT_DYNAMIC Fri Oct 13 13:49:38 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
Subsystem
assert
What steps will reproduce the bug?
assert.ok()docs says:I've called to it with an
Errorinstance as second argument, and instead of being thrown that error, it's being thrown anAssertionErrorwith it'smessagefield set to themessagefield of the provided error.Not sure what's the correct solution here, based on docs and common sense, the provided error should be thrown, but based on homogeneity, an
AssertionErrorshould be thrown (current behaviour) so it always throw anAssertionErrorno matter what it's provided as second argument...How often does it reproduce? Is there a required condition?
Always.
What is the expected behavior? Why is that the expected behavior?
Not sure if it's a bug, or a documentation issue.
What do you see instead?
AssertionErroris thrown, with provided Errormessage.Additional information
No response