I'm submitting a...

[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  
[x] Feature request
[x] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question

React recently introduced a concept called "Error Boundaries" (https://facebook.github.io/react/blog/2017/07/26/error-handling-in-react-16.html). Basically you wrap key areas of your app with .... and any component/template errors within can be handled at that level. I've run into issues with my Angular 4 app where an error in a component will cause the app to break ... sometimes the app is still navigable but often times rendering is messed up and the app just needs a restart. Most blog posts (and the Angular documentation) on error handling don't deal with rendering issues, just logging/handling any exceptions that may occur. What are strategies for gracefully handling "breaking errors" in an Angular app? Would something like make sense for Angular?

Edit: after discussing with @robwormald, it seems the current proscribed solution for handling uncaught errors would be to log them and then reload the entire app via the ErrorHandler mechanism already in Angular. This is still less than ideal (although ideally there would be no errors :-)). As applications grow, and as third party components are added/upgraded - it would be useful to introduce an the concept of an ErrorBoundary for two primary reasons:

1. allows more graceful and selective degradation of the app (if a child components underneath an ErrorBoundary fail, they can be restarted)
2. Error boundaries will introduce 'bulkheads' that ensure a single error won't sink the entire ship (forcing an app reload/restart), which will be more important the more likely errors are to occur (size of app, # external components, etc)