Just like in regular old JavaScript, you'll use try catch within your view components quite often. A pattern you'll see fairly regularly is inside of the catch block of your try catches. You will set some component state, some component reactive ref to the error that you caught. What this allows you to do is to actually display that error message within the component.
View. On click of this button, we're calling a function doThing, which throws an error, catches that error, and then sets some component state to the caught error. Inside of the template, if there's not an error, we display the button. But if there is an error, we display the error message.
The result is what you see over here in the browser. When I click the button, the error message appears. Okay, that's all well and good for components that are expecting errors just at a single level. They don't have any components nested down inside of them that could possibly catch errors, but Vue gives us another tool for handling errors within nested components.
vue, and here you can see a lifecycle hook called onErrorCaptured. OnErrorCaptured listens for any errors thrown within child components and will ultimately run if any of those child components throws an error, no matter how deeply nested the child component is down inside the component tree. So, this page component 2b-begin includes a component random error parent. If we open up the file structure here, in the components directory, you can see random error parent is just a button that throws an error, but it also includes another component, random error child.
Random error child, if we open that up, does the exact same thing. It has a button that throws an error, but then it also includes a random error grandchild component, which, as you probably guessed by now, has a button which throws an error. The idea here is that there's this deeply nested component that's not a direct child of the page component throwing errors, but it's the page component that runs the onErrorCaptured hook. Let's see what this looks like over in the browser.
I'll open up the corresponding page, and then you can see here all of those three buttons. Now I'm going to click on the button from the lowest descendant, that one that's most deeply nested. And when it throws that error, the page component that has the on error captured hook actually catches it and is able to show the error from that deeply nested component. That's exactly what you see right over here.
On error captured, it catches the error, sets it to some local error state, and then displays that error to the page if the error exists. Otherwise, it shows all those other components. Now, one thing you might have noticed here is that we're returning faults from onErrorCaptured. What's that doing?
Well, let me open up the console, and then I'll refresh the page, and I'll click... One of these buttons again. How about the middle one? Just to show you that it doesn't matter how deeply or how shallowly nested the component is on error captured will catch it.
So yeah, so now we're only console logging the error captured and then the error itself, which is what we're doing right here. But this is an error that's considered caught. There's nothing in the browser about us having an uncaught error. However, if I don't return faults here from onErrorCaptured, trigger an error again.
This time in the console, you'll see we have an uncaught error, error from child. So returning faults from onErrorCaptured means the error has been completely handled. But returning nothing or returning void from onErrorCaptured means go ahead and let the error continue to bubble up the component tree. You could also think of returning nothing from onErrorCaptured as the equivalent of re-throwing an error within a try-catch block.