-
Notifications
You must be signed in to change notification settings - Fork 30.1k
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
docs: why we use try-finally over try-catch #18711
Conversation
Unless I'm missing something, we can simplify the logic.
The difference is that the error was not caught before. But if you rethrow it after updating the cache I agree it would simplify the logic |
delete Module._cache[filename]; | ||
} | ||
} catch (err) { | ||
delete Module._cache[filename]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This silently suppresses the error. You need to throw err
.
lib/module.js
Outdated
} | ||
} catch (err) { | ||
delete Module._cache[filename]; | ||
throw err |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: Missing semicolon.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am against landing this. The reason to the current implementation is that the error does not have to be rethrown. Rethrowing is bad in the way that it changes the origin of the error to module.js
.
I guess adding a comment would be good though.
@BridgeAR I didn't know that. I thought the origin of the error was defined by where the Error object is instantiated. Can it also have some performance implication? |
So the stack frames stay the same but the output where the error was created will be different. It should not have any performance implications. |
+1 to adding a comment |
Hmm, I can think of a case where this might not be true. I will try to confirm it later today. |
This changes what is in cache if the error is caught from what would have previously been. Is this something we should pay attention to? |
Sorry, I don't understand why this is semver-major, the code looks equivalent (after the re |
Given that this changes the error output and requires a number of tests to be updated, should this even be landing? Using Not quite certain how I feel about this change. |
@apapirovski why/where does it change the error? |
@benjamingr It changes the origin, as mentioned above, hence all the failing tests. For example, instead of
we get
|
@apapirovski that's surprising to me, I thought stack traces are created when an error is created and not when it is thrown - so rethrowing an error shouldn't change the stack trace. Thanks. |
@benjamingr the stack trace is still identical. Just the origin changes. |
Thanks, so it changes the file name and not the trace - got it.
var e;
function a() {
function b() {
throw new Error();
}
b();
}
try {
a();
} catch (err) {
e = err;
}
function c() {
function d() {
throw e;
}
d();
}
try {
c();
} catch (err) {
console.log(err);
} Logs: Error
at b (<anonymous>:4:11)
at a (<anonymous>:6:3)
at <anonymous>:9:3 |
@benjamingr Yep, certain. The |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given this breaks tests and doesn't make the code much more readable - I'm -1 on this (since it'll require additional changes).
Thanks a lot for your contribution - and if you'd like help in finding things to work on feel free to ping me personally or ask.
@oliviertassinari if you would be willing to change your code to a comment that highlights why the current implementation is necessary, I am certain it will land :-) |
@BridgeAR Great. I'm on it. I wasn't expected as much activity. Thanks for the reviews. |
I have blamed the source and found #5172 as the origin of the change. It might performance related too. I'm abandoning this pull-request, cloning node is quick slow on my end:
Thanks for the feedback guys! |
Unless I'm missing something, we can simplify the logic.
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passesAffected core subsystem(s)