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: improve AssertionError in case of "Errors" #15025

Closed
wants to merge 1 commit into from

Conversation

BridgeAR
Copy link
Member

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 assert subsystem even though the AssertionError is placed in the internal/errors.

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • documentation is changed or added
  • commit message follows commit guidelines
Affected core subsystem(s)

assert

Showing the stack trace in a error message obfuscates the actual
message and should not be visible therefore.
@nodejs-github-bot nodejs-github-bot added the errors Issues and PRs related to JavaScript errors originated in Node.js core. label Aug 25, 2017
@BridgeAR BridgeAR added the assert Issues and PRs related to the assert subsystem. label Aug 25, 2017
@BridgeAR
Copy link
Member Author

Copy link
Member

@jasnell jasnell left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is likely a semver-major change

@jasnell jasnell added the semver-major PRs that contain breaking changes and should be released in the next major version. label Aug 25, 2017
@BridgeAR
Copy link
Member Author

@jasnell I personally would consider it as a bugfix as I highly doubt this was really anticipated and ever wanted behavior.

@jasnell
Copy link
Member

jasnell commented Aug 25, 2017

I would tend to agree. Let's see if others in @nodejs/ctc do also :)

@Trott
Copy link
Member

Trott commented Aug 25, 2017

I agree it's a bugfix, but a CITGM run for good measure wouldn't be a terrible idea.

@jasnell
Copy link
Member

jasnell commented Aug 25, 2017

When I'm actually able to get to CI I'll give it a run.

} else {
if (actual && actual.stack && actual instanceof Error)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't actual instanceof Error itself enough?

Copy link
Member Author

@BridgeAR BridgeAR Aug 26, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmmm.. actually, I believe .stack is a getter isn't it? It will have a performance impact also.

Copy link
Member Author

@BridgeAR BridgeAR Aug 26, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 :)

@BridgeAR
Copy link
Member Author

@BridgeAR
Copy link
Member Author

Ping @nodejs/ctc

@BridgeAR
Copy link
Member Author

BridgeAR commented Sep 2, 2017

Ping @nodejs/tsc PTAL

@BridgeAR
Copy link
Member Author

BridgeAR commented Sep 3, 2017

It would also be nice to get a comment about

@BridgeAR: I personally would consider it as a bugfix as I highly doubt this was really anticipated and ever wanted behavior.

@jasnell: I would tend to agree. Let's see if others in @nodejs/ctc do also :)

@Trott Trott removed the tsc-review label Sep 4, 2017
@BridgeAR
Copy link
Member Author

PTAL @nodejs/tsc (semver-patch / semver-major)

@targos
Copy link
Member

targos commented Sep 13, 2017

+1 for bug fix / semver-patch

@joyeecheung
Copy link
Member

+1 for semver-patch

@jasnell jasnell removed the semver-major PRs that contain breaking changes and should be released in the next major version. label Sep 14, 2017
@jasnell
Copy link
Member

jasnell commented Sep 14, 2017

@BridgeAR
Copy link
Member Author

Thanks a lot! Landed in 2e8217c

@BridgeAR BridgeAR closed this Sep 15, 2017
BridgeAR added a commit that referenced this pull request Sep 15, 2017
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 <[email protected]>
Reviewed-By: Joyee Cheung <[email protected]>
addaleax pushed a commit to addaleax/ayo that referenced this pull request Sep 17, 2017
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 <[email protected]>
Reviewed-By: Joyee Cheung <[email protected]>
@jasnell
Copy link
Member

jasnell commented Sep 20, 2017

This does not land cleanly on v8.x, a backport would be needed.

@BridgeAR
Copy link
Member Author

This should land cleanly as soon as #14167 got in. I open a backport for that in a few minutes.

jasnell pushed a commit that referenced this pull request Sep 21, 2017
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 <[email protected]>
Reviewed-By: Joyee Cheung <[email protected]>
@jasnell
Copy link
Member

jasnell commented Sep 21, 2017

landed in v8.x-staging. Thank you!

Qard pushed a commit to Qard/ayo that referenced this pull request Sep 21, 2017
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 <[email protected]>
Reviewed-By: Joyee Cheung <[email protected]>
@MylesBorins
Copy link
Contributor

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

@apapirovski apapirovski mentioned this pull request Dec 9, 2017
4 tasks
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. errors Issues and PRs related to JavaScript errors originated in Node.js core.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants