Overview-robustness
In the daily business development process, we put a lot of attention on the realization of the needs of the business itself. Less effort may be invested in the exception handling of the program. However, for the robustness of a program, exception handling is a very, very important part.
error boundary
This is an error downgrading solution provided by the official website after React16.
Solved part of the problem
Looking at the above document, this error boundary solution can only solve the following exceptions.
- Render during rendering
- Life cycle approach
- The constructor of the entire component tree
ok, it can be caught only when an exception occurs in these 3 cases.
However, this kind of error can bubble up, which means that if you use the ErrorBoundary component at the top level of the component, you can catch the exception of the entire component tree. Of course, you can also nest it in multiple places.
There is nothing to explain, the official documentation is clear enough.
Unsolvable problem
Errors that cannot be caught by the error boundary:
- Event handling
- Asynchronous code
- Errors thrown by itself (not its child components)
- Server-side rendering
How to catch exceptions in these scenarios?
Let's roughly analyze the possible solutions below
try/catch
What we can instinctively think of or often use may be the try/catch statement.
It can really help us catch many exceptions and avoid program crashes.
Of course try/catch is done once and for all, of course not. It has two very obvious shortcomings:
- Can only catch exceptions generated in synchronous programs
- Exporting and writing trg/catch is really annoying
unhandledrejection
Promises are now rotten on the streets, flooded with disasters. There are then cases where there is no catch everywhere.
At this time, if an exception occurs, we will see an error such as Uncaught (in promise) in the console.
At this time, you can monitor the unhandledrejection error event, which is specifically used to handle the uncaught exception of the promise
window.addEventListener("unhandledrejection", event => {
console.warn(`UNHANDLED PROMISE REJECTION: ${event.reason}`);
});
error
The biggest killer is to monitor error events, and the previous error log collection system is mainly based on this thing.
window.addEventListener('error', this.onError, true);
Is there an integration plan
There are so many rough divisions above, ah, it's still annoying to look at, you need to write everywhere by yourself and deal with it manually everywhere.
Can you just abstract, is there a wheel that can be used...Hurry up and search for it in the open source community.
to 160d2dc64bd984 npm.js official website enter keywords, it really comes out a lot
to sum up
This is just a simple thinking and recording, and there is no energy to study very in-depth at present.
But generally speaking, it is the basic things that solve the anomaly, and the foundation is the cornerstone of everything.
The rest is how to abstract and encapsulate a more usable library, which is the skill of making wheels.
However, the open source community resources are huge and can be used for reference.
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。