Welcome back. In earlier video, you understood about global error and applications global error handler, I wrote my own error handler global. And then I made this as default global handler by going to global elements in the configuration. I refer to this global handler, global error handler as default. So my global handler became the default. In a later video at the last I was telling that in your flow for having an error handler, which is not even matching, actually, the X the error type, which is propagated here is my one error and my one error type, right.

So my one error type With propagated AP currency where a type is propagated, there is no error handler for that particular error. But still there is one error handler, right. So in this case, the applications default global handler is not executed the actual default handler of mule mules default handlers executed let me show you with presentation. Just try to understand if a flow has an error handler the error is handled by the first errors co cause condition evaluates to true. So my main flow is having an error handler. But is it having error handler?

Error scope? Which is matching the condition? There are? No So none of them was executed, right? So if no score conditions are true, error is handled by mules default error handler not any scope in applications global handler is important for certification, your applications global handler will not be executed mules default error handler will get executed. So, in this case actually when I gave a request, this web service consumer is not able to make a connection.

So what this is doing is mapping this WC cannot dispatch to app called server cannot dispatch. So this is the error type which is propagated. So is there an error handler? No. It come to valid in transform. It'll execute and it'll get propagated here.

So when it got propagated for my main group, There is an error handler that is in error handling but more condition is not matching. So, this error scope is not mapped. So, in this case what will happen is the global default handler is executed. Now, if this was executed if this was executed here the logger whatever I have written in inside on error continue that should have been seen that should have been seen but did I see it? No, only I saw the logger and validate Floyd it says logger that means, the applications default handler was not executed but mules default error handler got executed. So, since we use default handler got executed it propagates rock right.

That there may be many handling So, Since your default handler got executed, I was able to see this response to an app called server count as patch, right. So, keep this in mind, this is one interesting thing, which can appear in certification, if a flow does not have error handler, any error handler at all. So, that means, if I remove this error handler for my main flow, it does not have any error handler. So now the error propagate, and now the applications default error handler will be executed. So if a flow does not have an error handler, that error is handled by a scorpion applications default error handler, right. Okay, so this is one point I want you to understand.

Clearly. You have to see the same thing I'm describing using the diagrams. See here, there is a main flaw here error occurs there is no error. And applications default handler is not having any matching scope, this is a scenario. So, what will happen error is thrown and there is no applications default handler matching scope. So, Miss default error handler got executed error is thrown and HTTP will HTTP listener will return error response, this is scenario one, scenario two.

So, in my main flow, there is no error handler but the application default handler has a maximum scope. So what happens when error occurs here, applications default handler got executed and there is return then the history listener will return either success or error when it will return success. can guess in the default error handler application specifically fault handler. If you're handling using on error continue then you will see success in the default error handler. If you're handling using on error propagate then there will be propagated, so error will be shown right. So, in the default error handler, if you have used on error continue, then success will be returned by the listener.

If you have used on error propagate then error response might be written. Okay. So next scenario. See, in the calling flow, there are error handlers. Error scopes, periscopes. It's not thing magic.

So, in your flow there are scopes this error handler, which is having some scopes. Now, as I told you, the error gets thrown, the applications default handler will not be executed the new default handler got executed and error responses returned. Then last one. Here in my calling flow, there are error scopes with no matching and applications default error with matching scope again will this be executed? No, the default handler only will be executed. These are the various scenarios which I want to harness then finally, I want to tell you how to throw your so what I will do is right now in the main floor, not handling.

So to come here to the report handler Now here what I can do is I can raise my own error by just dragging and dropping raised and here or the type I will say type is equals to App colon my own type see was on and so, by using razor, I can actually raise my one error type so I will stop this application and then restart it. Okay, so now we will request to same URL let us see the response I will be getting See was on error Ty Is it the description of this. So, if we see the console you can see the error message is logged actually my one error type which is which is raised again at the end and you can see the error type which is logged is actually the this is the lock methods present in the global handler. The server can cc was on error type is raised is it so in the global handler actually what I have written I have written this one did I see this one in inside honor continue?

Yes. I saw Yes, right. So the default handle got executed and you raise your own error type this is shown, right? So now you understood how to raise your own error types by using raise error. That's all I want to talk about error handling in mule for. Thank you and I'll see you next module.