-
Notifications
You must be signed in to change notification settings - Fork 8.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
Should we handle uncaughtException
s?
#183182
Comments
Pinging @elastic/kibana-core (Team:Core) |
Pinging @elastic/kibana-operations (Team:Operations) |
This feels like such an easy thing to miss, especially when dealing with RxJS which can already be confusing enough. I'm not sure how we could differentiate between exceptions we want to crash, and ones we want to prevent crashing... but if we could come up with a strategy for it, I think it'd be worth considering. Or alternatively maybe we catch exceptions and continue to crash, but try to log the error in a more uniform way that's easier to monitor? 🤷 |
We should fix unhandled exceptions rather than blindly catching them all. We can't know for certain how Kibana is going to react and will probably lead to very unexpected behavior (if working at all that is!) |
We can always consider a more global option to catch exceptions, as long as it's opt-in only. |
So, I assume such errors would / should only be thrown from Core code, correct? If so, we might be able to re-use the concept of "critical errors" and manually "flag" errors that should crash the process.
OTOH, from the nodeJS documentation itself:
So I agree with the previous statements from @lukeelmers and @TinaHeiligers that still crashing while properly logging the error cause / stack may be the best approach. OTOOH, usually rxjs stack traces are not helpful at all, and don't have any context information of the original code / caller, so I wonder if logging the stack trace in such scenario would really help us in any way (aside from knowing for sure that an uncaught error was the cause of the process termination) |
++ I agree with you all: at the moment, the best handling we can do is logging before we crash. |
I noticed that running the piece of code below logs
Uncaught Exception error: Error: Something went terribly wrong.
We have a lot of patterns where we run promises inside
exhaustMap
/switchMap
/concatMap
in RxJS. We are already handling unhandled rejections, but we don't do so for exceptions. Should we?How would we handle intentional crashing errors, though?
The text was updated successfully, but these errors were encountered: