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

assert.ok() throwing AssertionError instead of provided Error object #50780

Closed
piranna opened this issue Nov 18, 2023 · 26 comments · Fixed by #53980 · May be fixed by #51250
Closed

assert.ok() throwing AssertionError instead of provided Error object #50780

piranna opened this issue Nov 18, 2023 · 26 comments · Fixed by #53980 · May be fixed by #51250
Labels
assert Issues and PRs related to the assert subsystem. good first issue Issues that are suitable for first-time contributors.

Comments

@piranna
Copy link
Contributor

piranna commented Nov 18, 2023

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:

If the message parameter is an instance of an Error then it will be thrown instead of the AssertionError.

I've called to it with an Error instance as second argument, and instead of being thrown that error, it's being thrown an AssertionError with it's message field set to the message field 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 AssertionError should be thrown (current behaviour) so it always throw an AssertionError no 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?

AssertionError is thrown, with provided Error message.

Additional information

No response

@climba03003
Copy link
Contributor

node/lib/assert.js

Lines 396 to 398 in 25fdb48

} else if (message instanceof Error) {
throw message;
}

It clearly re-thrown if the message is instanceof Error, but instanceof checking 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'))

@VoltrexKeyva VoltrexKeyva added the assert Issues and PRs related to the assert subsystem. label Nov 19, 2023
@MrJithil
Copy link
Member

This 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.

@piranna
Copy link
Contributor Author

piranna commented Nov 22, 2023

instanceof checking may not be true depends on testing framework

My fault... I'm using Jest, and forget it has problems with instanceof and builtin classes 🤦🏻. Could make it sense to use ducktyping and check for Error objects fields? Based on spec, message, name and stack can made us pretty sure they are Error objects themselves...

@targos
Copy link
Member

targos commented Nov 22, 2023

We could use the same algorithm as util.isError:

node/lib/util.js

Lines 167 to 169 in 1858341

function isError(e) {
return ObjectPrototypeToString(e) === '[object Error]' || e instanceof Error;
}

@piranna
Copy link
Contributor Author

piranna commented Nov 22, 2023

We could use the same algorithm as util.isError

It's deprecated, and also it would not work for Error child classes.

@targos
Copy link
Member

targos commented Nov 22, 2023

The function is deprecated, but not what it does. It works fine with child classes.

@piranna
Copy link
Contributor Author

piranna commented Nov 22, 2023

It works fine with child classes.

I think it wouldn't, because on child classes, the prototype constructor name would be different of Error string, so the comparison would fail and we would get to the e instanceof Error, leading to the same Jest error we have here in this issue.

@targos
Copy link
Member

targos commented Nov 22, 2023

If you don't believe me, try it

@BridgeAR
Copy link
Member

We can also add a check that looks util.types.isNativeError(). That is how assert itself checks for errors next to instanceof.

@BridgeAR BridgeAR added the good first issue Issues that are suitable for first-time contributors. label Dec 18, 2023
@piranna
Copy link
Contributor Author

piranna commented Dec 18, 2023

I like the idea.

@NiharPhansalkar
Copy link
Contributor

Hello, I would like to try and work on this issue.

@piranna
Copy link
Contributor Author

piranna commented Dec 20, 2023

What do you need?

@NiharPhansalkar
Copy link
Contributor

Seeing the discussion, I will try to implement both the methods mentioned to see if it actually throws the required error. Will update accordingly?

@piranna
Copy link
Contributor Author

piranna commented Dec 20, 2023

The wrong Error class is being dispatched due to using Jest, it's a bug there due to how it manage native classes. Proper solution should be done there, but in addition to that, a isNativeError() function can be useful too, at least to bypass the problem here and in other places.

@NiharPhansalkar
Copy link
Contributor

So you initially want to check if a function similar to isNativeError() returns true, and if it does, just directly throw that error instead of bothering with how instanceof is treated?

@piranna
Copy link
Contributor Author

piranna commented Dec 20, 2023

I think so, yes.

@NiharPhansalkar
Copy link
Contributor

@piranna Is there any way to get Jest to use my local nodejs? i.e the node I have in node/out/Release/node?

I tried searching around but can't find much. Maybe you have tried this before?

@piranna
Copy link
Contributor Author

piranna commented Dec 20, 2023

Compile your Node.js, and launch Jest with It.

@NiharPhansalkar
Copy link
Contributor

I have compiled my node, how do I launch Jest with it? Is there some particular config option for it? Or a command line flag?

@targos
Copy link
Member

targos commented Dec 20, 2023

out/Release/node path/to/jest/cli.js

NiharPhansalkar added a commit to NiharPhansalkar/node that referenced this issue Dec 21, 2023
Added the function for compliance with
frameworks such as Jest

Fixes: nodejs#50780
NiharPhansalkar added a commit to NiharPhansalkar/node that referenced this issue Dec 24, 2023
Added the function for compliance with
frameworks such as Jest

Fixes: nodejs#50780
NiharPhansalkar added a commit to NiharPhansalkar/node that referenced this issue Dec 24, 2023
Added the function for compliance with
frameworks such as Jest

Fixes: nodejs#50780
NiharPhansalkar added a commit to NiharPhansalkar/node that referenced this issue Dec 28, 2023
Added the function for compliance with
frameworks such as Jest

Fixes: nodejs#50780
@ignaciosuarezquilis
Copy link

Hi, can I work on this issue?

@piranna
Copy link
Contributor Author

piranna commented May 7, 2024

Hi, can I work on this issue?

Sure, go for it :-)

@Naveen-2021ucp1387
Copy link

is this issue still open ?

@piranna
Copy link
Contributor Author

piranna commented May 15, 2024

Yes, it's still a problem.

@pmarchini
Copy link
Member

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.

nodejs-github-bot pushed a commit that referenced this issue Jul 28, 2024
Co-Authored-By: Ruben Bridgewater <[email protected]>
Co-Authored-By: Nihar Phansalkar <[email protected]>
PR-URL: #53980
Fixes: #50780
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Ruben Bridgewater <[email protected]>
Reviewed-By: Marco Ippolito <[email protected]>
@piranna
Copy link
Contributor Author

piranna commented Jul 28, 2024

Great, good work @pmarchini :-)

targos pushed a commit that referenced this issue Jul 30, 2024
Co-Authored-By: Ruben Bridgewater <[email protected]>
Co-Authored-By: Nihar Phansalkar <[email protected]>
PR-URL: #53980
Fixes: #50780
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Ruben Bridgewater <[email protected]>
Reviewed-By: Marco Ippolito <[email protected]>
RafaelGSS pushed a commit that referenced this issue Aug 5, 2024
Co-Authored-By: Ruben Bridgewater <[email protected]>
Co-Authored-By: Nihar Phansalkar <[email protected]>
PR-URL: #53980
Fixes: #50780
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Ruben Bridgewater <[email protected]>
Reviewed-By: Marco Ippolito <[email protected]>
marco-ippolito pushed a commit that referenced this issue Aug 19, 2024
Co-Authored-By: Ruben Bridgewater <[email protected]>
Co-Authored-By: Nihar Phansalkar <[email protected]>
PR-URL: #53980
Fixes: #50780
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Ruben Bridgewater <[email protected]>
Reviewed-By: Marco Ippolito <[email protected]>
marco-ippolito pushed a commit that referenced this issue Aug 19, 2024
Co-Authored-By: Ruben Bridgewater <[email protected]>
Co-Authored-By: Nihar Phansalkar <[email protected]>
PR-URL: #53980
Fixes: #50780
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Ruben Bridgewater <[email protected]>
Reviewed-By: Marco Ippolito <[email protected]>
marco-ippolito pushed a commit that referenced this issue Aug 19, 2024
Co-Authored-By: Ruben Bridgewater <[email protected]>
Co-Authored-By: Nihar Phansalkar <[email protected]>
PR-URL: #53980
Fixes: #50780
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Ruben Bridgewater <[email protected]>
Reviewed-By: Marco Ippolito <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
assert Issues and PRs related to the assert subsystem. good first issue Issues that are suitable for first-time contributors.
Projects
None yet
10 participants