From the documentation and design documents, it looks as if I cannot use ErrorBoundary to catch unhandled exceptions and to show an error page to the user:
Documentation on ErrorBoundary:
We recommend narrowly scoping error boundaries in most scenarios.
Design proposal for ErrorBoundary:
Non-goals:
- Changing what it means to do global exception handling. We already have ILogger for logging, and beyond that, truly unhandled exceptions mean the app is in an undefined state which is unsafe to continue.
and
Error boundaries are not expected to catch all possible exceptions. We're trying to cover ~90% of the most common scenarios, (...)
and
Developers might think that all possible exceptions will be caught and become recoverable. This doesn't put server stability at risk, but just means the developer will be surprised when the terminal error UI still can appear.
and
Developers might think they don't need to customize terminal error UI any more. It may be confusing that there are multiple different error UIs to customize (one per error boundary, and a final terminal one).
So, why shouldn't I use ErrorBoundary for this? I agree that recovering from an unhandled exception might not be desirable; but what if I don't allow recovery from this global ErrorBoundary?
If I shouldn't use ErrorBoundary, what should I use to show an error page to the user? Currently the UI just freezes and a message is shown in the Developer Console of the browser. The design proposal talks about "terminal error UI", but I find no reference to this in the documentation.
And if ErrorBoundary is the way to go; how do I cover the remaining ~10% to show an error message to the user when their circuit has fried?