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

Fix exception not printed when debugging #219

Merged
merged 1 commit into from Aug 9, 2018
Merged

Fix exception not printed when debugging #219

merged 1 commit into from Aug 9, 2018

Conversation

mohd-akram
Copy link
Contributor

This is based on my comment in PR #208 which caused exceptions not to be printed to the console when debugging (eg. using Chromium or VS Code). I've also simplified the code a bit.

@LinusU
Copy link
Collaborator

LinusU commented Jul 23, 2018

I think the problem with just setting process.exitCode is that it doesn't actually terminate the process, which I think is the expected outcome.

Would it be possible to keep the current behavior if fs is available?

@mohd-akram
Copy link
Contributor Author

fs is always available, we need to check if we're running in debug/inspect mode. I've found one way to do this using the inspector module, but right now browserify returns an error when using it, pending browserify/browserify#1854. In the meantime, I've updated the PR to use process.exit().

@LinusU
Copy link
Collaborator

LinusU commented Jul 25, 2018

Unfortunately calling process.exit right after calls to console.error won't make sure that the output is flushed, and will more often than not result in cut off text. That's why it used fs.writeSync before.

@mohd-akram
Copy link
Contributor Author

Is it really more often than not though? I think this problem only happens when you're printing large amounts of text (see nodejs/node#6456). Also, the switch from console.error to fs.writeSync seems to have happened only a few months ago and both the issue and PR for it did not give a way to actually cause the bug as far as I can tell.

A possible workaround mentioned in the node issue I linked is to add process.stderr._handle.setBlocking(true); before printing and exiting.

@LinusU
Copy link
Collaborator

LinusU commented Jul 26, 2018

process.stderr._handle.setBlocking(true); sounds good, can you add it? 👍

@mohd-akram
Copy link
Contributor Author

I've updated the PR.

process.exit(1);
}

function shimEmitUncaughtException () {
var origEmit = process.emit;
process.on('uncaughtException', function(error) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Is there a specific reason for changing this? It will change the before behavior of not exposing us in process.listeners('uncaughtException'). I'm not saying that one way or the other is better, but we could potentially break something that depended on it not showing up...

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Taking over process.emit seemed like overkill IMO and a non-standard way of doing it. Not directly related to this PR, however.

@mohd-akram
Copy link
Contributor Author

mohd-akram commented Aug 9, 2018

I've simplified the PR to just the necessary changes.

@LinusU
Copy link
Collaborator

LinusU commented Aug 9, 2018

Thank you!

@LinusU LinusU merged commit a52d786 into evanw:master Aug 9, 2018
@LinusU
Copy link
Collaborator

LinusU commented Aug 9, 2018

Published as v0.5.7 🚢

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants