Where to put the unhandled error event hook? Looking for ideas/thoughts
See original GitHub issueFor version 6, we need to remove the error rethrowing behavior for Observables. Basically this means that if an error propagates to the end of an Observable chain, it will no longer be rethrown, rather, it will be reported to a global error handler. There are a variety of reasons for this that have already been discussed, so I don’t want to discuss those here, but the thing we need to know is, where should we put this error handler?
Prior Art: Promises
Promises allow handling unhandled rejections via window.addEventListener('unhandledrejection', handler)
in a browser or process.on('unhandledRejection', handler)
in Node.
Caveats
- It’s entirely likely that this solution might change with whatever the spec does.
- initially, we might just have it log until we can figure out where the eventing should exist.
Issue Analytics
- State:
- Created 6 years ago
- Comments:12 (7 by maintainers)
Top Results From Across the Web
Managing Unhandled Exceptions in .NET - CodeProject
NET's unhandled exception event handlers. This means that we'll just have one error handler to handle all unhandled exceptions.
Read more >Apex class for unhandled exceptions - IdeaExchange
Log all unhandled exceptions in a custom object, platform event, etc. Replace unhandled exception with a more generic one with a message like...
Read more >c# - Writing file asynchronously in unhandled exception handler
I'm writing handler for Unhandled Exception event which we will dump an exception to a file and then send to a server for...
Read more >Error/Exception handling in Vue.js application | by Arun Redhu
We can register a handler function which will capture all the unhandled exceptions which are not specific to Vue instances. The following code ......
Read more >Best Practices for Node.js Error-handling - Toptal
on('unhandledRejection', callback) . The typical error-handling flow might look like the following: // somewhere in the code ... User.getUserById( ...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
I think for observables, which don’t have the “can be handled later” problem that promises have, you just want to deliver it to the global scope. That basically means
setTimeout(() => { throw err; }, 0)
. In browsers that will fire anerror
event on the appropriate window (which window is pretty complicated…) and in Node it will cause crashes.That’s what HostReportErrors means in the spec, as well.
More of an FYI than a serious suggestion:
Gets reported just like if throwing inside a setTimeout but syncronous. So appears in log at the correct place.