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

NodeUp: Hardening for Error Propagation and Post-Mortem Debugging #60

Open
ScottONeal opened this issue Feb 9, 2016 · 3 comments
Open

Comments

@ScottONeal
Copy link

After reading through this issue: nodejs/post-mortem#16
and trying to establish my own battle hardened methodology for handling uncaught errors at run time and debugging post-mortem. It would be nice to have a conversation on industry best practices for designing your application to provide the maximal amount of information for debugging. I think this should also include industry best practices for what to properly do for uncaughtException and unhandledRejection. Or, do I just always run with: --abort-on-uncaught-exception.

What are the best tools for understanding core files and how I can we bring this process out from the Node.js Ivory Tower?

Maybe this topic is a bit too technical for a podcast, but it would be nice to have a dialog about the state of production debugging and exception handling. What are the best practices and what is overkill.

@dshaw
Copy link
Member

dshaw commented Feb 9, 2016

@ScottONeal Great topic. I have some producty answers to this topic. Beyond that work, the teams at Netflix, Joyent and Uber are doing some really interesting work in this space. Notably, these are all orgs that have either never gone Promises or have had to eliminate them to maintain observability. It would be nice to mix in a more positive Promises story too if it exists.

In the interim, folks definitely need to check out @StinkyDofu's To Err is Human talk: https://enterprisejs.io/events-sfbay002/ . So good!

@ScottONeal
Copy link
Author

Thanks for the resource @dshaw! I have also noticed the traceability issues with promises and have tried to remove them, when possible.

Seems like Promises have introduced themselves almost everywhere in the ecosystem, while it's a nice abstraction, the costs/complexity are becoming a bit expensive when debugging!

@chrisdickinson
Copy link

I'd be happy to represent the promises use-case if this comes up!

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

No branches or pull requests

3 participants