| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
There was a problem hiding this comment.
What do others think about actually throwing in such a case? I personally think it would be best to only accept null and undefined.
Sorry, something went wrong.
There was a problem hiding this comment.
I agree, it's already semver-major so let's do it. Can you also update the PR description with this change?
Sorry, something went wrong.
There was a problem hiding this comment.
Done.
Sorry, something went wrong.
Sorry, something went wrong.
There was a problem hiding this comment.
I'm thinking this might not be a good idea.
If an error we didn't want is passed, I think we prefer to see the original stacktrace and not the new one.
Sorry, something went wrong.
There was a problem hiding this comment.
if you remove await there is no need for this to be an async function.
Sorry, something went wrong.
There was a problem hiding this comment.
Hm, true. I am not sure why it was a async function in the first place. I guess a oversight.
Sorry, something went wrong.
|
@mcollina about the changed stack trace: you should have both. You can access the original stack trace by checking the actual property. I could also combine the stack traces (I thought about it before but I rejected it again) if that feels better to others. |
Sorry, something went wrong.
|
If you put it in actual, most testing frameworks would not print it by default. Then, the information will be lost. |
Sorry, something went wrong.
|
@mcollina I rewrote this to extend the actual error with the necessary frames. So now you get a combined stack that is way more informative than before. |
Sorry, something went wrong.
Sorry, something went wrong.
There was a problem hiding this comment.
the goal of this code is not really clear, can you add some comments?
Sorry, something went wrong.
There was a problem hiding this comment.
Done.
Sorry, something went wrong.
There was a problem hiding this comment.
I would prefer a test showing a full stack trace, rather than this check. It would mean future edits are easier to understand and fix.
Sorry, something went wrong.
There was a problem hiding this comment.
I added a separate test to check for the stack trace and minimized this test to the necessary parts.
Sorry, something went wrong.
There was a problem hiding this comment.
I agree, it's already semver-major so let's do it. Can you also update the PR description with this change?
Sorry, something went wrong.
It is hard to know where ifError is actually triggered due to the original error being thrown. This changes it by wrapping the original error in a AssertionError. This has the positive effect of also making clear that it is indeed a assertion function that triggered that error. The original stack can still be accessed by checking the `actual` property.
Destructure the necessary Error classes from internal/errors. This improves the readability of the error creation.
This makes `assert.ifError` stricter by only accepting `null` and `undefined` from now on. Before any truthy value was accepted.
There was a problem hiding this comment.
LGTM
Sorry, something went wrong.
It is hard to know where ifError is actually triggered due to the original error being thrown. This changes it by wrapping the original error in a AssertionError. This has the positive effect of also making clear that it is indeed a assertion function that triggered that error. The original stack can still be accessed by checking the `actual` property. PR-URL: nodejs#18247 Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
Destructure the necessary Error classes from internal/errors. This improves the readability of the error creation. PR-URL: nodejs#18247 Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
This makes `assert.ifError` stricter by only accepting `null` and `undefined` from now on. Before any truthy value was accepted. PR-URL: nodejs#18247 Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
|
Looks like this may have landed without a clean CI run? In any event, the message test added here seems to be failing 100% of the time on Windows CI. (Am I wrong somehow about that?) Is there a PR to fix that or should we revert until it's fixed? |
Sorry, something went wrong.
|
Oh, I see the problem. It's expecting forward slashes, but on Windows, the path separator is (of course) backslashes. Opening a PR to fix. |
Sorry, something went wrong.
Sorry, something went wrong.
Destructure the necessary Error classes from internal/errors. This improves the readability of the error creation. PR-URL: nodejs#18247 Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
It is hard to know where ifError is actually triggered due to the original error being thrown. This changes it by wrapping the original error in a AssertionError. This has the positive effect of also making clear that it is indeed a assertion function that triggered that error. The original stack can still be accessed by checking the `actual` property. PR-URL: nodejs#18247 Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
Destructure the necessary Error classes from internal/errors. This improves the readability of the error creation. PR-URL: nodejs#18247 Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
This makes `assert.ifError` stricter by only accepting `null` and `undefined` from now on. Before any truthy value was accepted. PR-URL: nodejs#18247 Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
| Back | FazBrowse Home | New Git URL |
It is hard to know where ifError is actually triggered due to the
original error being thrown.
This changes it by wrapping the original error in a AssertionError.
This has the positive effect of also making clear that it is indeed
a assertion function that triggered that error.
The original stack can still be accessed by checking the actual
property.
Show only the Error class and not errors.AssertionError.
Make ifError stricter by only accepting null and undefined from now on.
Before any truthy value was accepted.
Checklist
Affected core subsystem(s)
assert