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

Standard errors tracking #47

Open
kaievns opened this issue Apr 18, 2016 · 4 comments
Open

Standard errors tracking #47

kaievns opened this issue Apr 18, 2016 · 4 comments

Comments

@kaievns
Copy link
Contributor

kaievns commented Apr 18, 2016

This is a must have. It just plummets my performance if errors are not handled properly both in dev and prod.

I saw you added the unhandledRejects, but I don't think that cuts it. You need to have logged the errors somewhere like sentry or airbrake in prod and it should properly capture the context and stack trace. Also in dev it should show a proper and meaningful stack-trace + don't crash and automatically reboot when changes to the code are made

@davidbanham
Copy link
Contributor

Yep, great logging and error tracking is definitely something we need to have.

In my mind, there's a piece of work to be done around togglable info level logging in the routes, resources, etc.

And yes, we should definitely tune up the unhandledRejection code to print the stack trace along with the reason.

https://github.com/Prismatik/redbeard/blob/0775bb2013621dc0c2c989ec61de79ef609bd215/base/index.mustache#L25

don't crash and automatically reboot when changes to the code are made

That's a job for a bin script with something like chokidar rather than the error reporter, IMO.

@kaievns
Copy link
Contributor Author

kaievns commented Apr 18, 2016

That's a job for a bin script with something like chokidar rather than the error reporter, IMO.

totally agreed. just thought it could part of this ticket. to make sure that as a dev i have it all setup properly by the generator

@davidbanham
Copy link
Contributor

I'm going to create a new ticket for it. Purely because the autorunner is a simple thing someone might pick up in a spare 15 minutes, whereas the logging piece is a bigger job.

@kaievns
Copy link
Contributor Author

kaievns commented Apr 18, 2016

agreed, makes total sense

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

2 participants