assert: improve AssertionError in case of "Errors" #15025
Conversation
Showing the stack trace in a error message obfuscates the actual message and should not be visible therefore.
nodejs-github-bot
added
the
errors
jasnell
added
the
semver-major
|
@jasnell I personally would consider it as a bugfix as I highly doubt this was really anticipated and ever wanted behavior. |
|
I would tend to agree. Let's see if others in @nodejs/ctc do also :) |
|
I agree it's a bugfix, but a CITGM run for good measure wouldn't be a terrible idea. |
|
When I'm actually able to get to CI I'll give it a run. |
| } else { | ||
| if (actual && actual.stack && actual instanceof Error) |
There was a problem hiding this comment.
Isn't actual instanceof Error itself enough?
There was a problem hiding this comment.
It is but it has a performance implication (it might not be important because it is only about errors but it is something that I always like to consider).
There was a problem hiding this comment.
Hmmm.. actually, I believe .stack is a getter isn't it? It will have a performance impact also.
There was a problem hiding this comment.
@jasnell util.inspect will look at the stack as well. The first call to the stack is heavy and it does not matter if it is done here or later on (well it is actually not anymore as we only pass a string through instead of the error but the performance for the error will stay the same as before and the average case wont have any negative hit).
There was a problem hiding this comment.
So yes, it would be faster for Error objects (the instanceof check is added on top of the stack access) but slower for the average case.
There was a problem hiding this comment.
Yeah. Hmm. It's likely fine. Doing it the same way internal/util isError does would likely be ok also but I'm good with it :)
|
Ping @nodejs/ctc |
|
Ping @nodejs/tsc PTAL |
|
PTAL @nodejs/tsc (semver-patch / semver-major) |
|
+1 for bug fix / semver-patch |
|
+1 for semver-patch |
jasnell
removed
the
semver-major
|
Thanks a lot! Landed in 2e8217c |
Showing the stack trace in a error message obfuscates the actual message and should not be visible therefore. PR-URL: #15025 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Showing the stack trace in a error message obfuscates the actual message and should not be visible therefore. PR-URL: nodejs/node#15025 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
|
This does not land cleanly on v8.x, a backport would be needed. |
|
This should land cleanly as soon as #14167 got in. I open a backport for that in a few minutes. |
Showing the stack trace in a error message obfuscates the actual message and should not be visible therefore. PR-URL: #15025 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
|
landed in v8.x-staging. Thank you! |
Showing the stack trace in a error message obfuscates the actual message and should not be visible therefore. PR-URL: nodejs/node#15025 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
|
This does not land cleanly in LTS. Please feel free to manually backport by following the guide. Please also feel free to replace do-not-land if it is being backported |
Showing the stack trace in a error message obfuscates the actual
message and should not be visible therefore.
I think this is actually part of the
assertsubsystem even though theAssertionErroris placed in the internal/errors.Checklist
make -j4 test(UNIX), orvcbuild test(Windows) passesAffected core subsystem(s)
assert