-
Notifications
You must be signed in to change notification settings - Fork 398
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
Add code comment to explain conditional throw on unCaught exceptions #220
Conversation
Also, I didn't see in the README or CONTRIBUTING docs how to file an "issue". It appears that the test suite has no test for the case for your uncaught exception handling when there are multiple handlers. It's an important case to check because in one case you re-throw the error and in the other case you don't. (If the test is there but I missed it, perhaps the test name could use a more explicit label). This case is important for people who may be combining the It appears you may have an unstated expectation that if there are multiple listeners for this event that the other other event will fire /after/ the newrelic event and that /it/ throws an error and shut's down. If the other event ran first and shut down the process, the newrelic process would never fire. This is never supposed to happen because you advise to always load the newrelic module first, but a local code comment about that expectation could still be helpful. Second, what happens if the other module behaves in a similar way and /also/ choose not to shutdown the process after the uncaught exception is handled, like New Relic does? Test coverage could and code comments or docs could help clarify your intent for the case of when the |
Hi Mark, Thanks for the PR! More comments are always good and we'll try to roll this into the next release.
This is the correct way to file an issue with the agent. :) We should make that more clear in the contributing doc though.
The test case is in test/integration/core/exceptions.tap.js and is titled "caught uncaught exceptions." Our tests are definitely not the most straightforwardly organized, but it is all there.
The order of the other handlers doesn't matter to us. If another handler takes that error and then rethrows it your server will crash and you'll know about the error from that, the same as the case were we are the only error handler. Our check for that listener count is simply an attempt at maintaining the normal behavior of your server if NR were not installed. |
Thanks for the response. I've done some testing now with a "Hello World" script testing to see what happens when both New Relic and BugSnag are loaded. It appears that both NR and BugSnag both handle the exception as expected and the program exits-- all good.
Reference: http://www.slideshare.net/domenicdenicola/domains-20010482 ( Some slides reference how process._fatalException is used as part of the domains feature ). |
We use I agree with you regarding comments though. More comments are always good, and PRs are accepted. :) |
Release v7.0.3
Release v7.0.3
It wasn't clear at first why you would throw sometimes but others here, so I researched and added a comment to leave a hint for the next code reader.