In this video, you're going to understand error handling in mule four, if you are a mule three user and let's turn that the error handling in new three is totally different than the error handling in metaphor. It is very interesting in mule for let us say step by step. A typical flow normally contains error handling block Also, if you see this one, there is error handling in every error handling block, you can actually configure something called as error handlers. Let's see what will happen if an exception occurs in any one of the flow cities diagram. Let's assume that in this flow, third event processor is throwing an exception the subsequent event process in the flow are not executed. And in the flow if you have defined any error handlers, the subsequent error handler will be executed Okay, so let us practically see what will happen.

According to one scenario, I'll explain you a lot of other things. So if you see, I'll be working on this exception start project. Here, I already have defined three flows. First flow is taking HTTP request using the listener, the main flow source is the URL slash error. Then the next one is actually setting a variable extracting a query parameter colors, product name. So, it is expecting a product name as query parameter.

Now, we are calling the next flow, validate in transform flow. So let's see what is this valid in transform flow. I'm using something called a validator. There are configured a yeast to validator in our country. record is an expression, which says, say this is a listing dw, right? So, actually, this expression will evaluate Pro, if there's a query parameter called us product name.

And it's value should be either HP or Mac. So, if there is no query parameter called as product name, then and if it is not even Mac, then this validator is going to throw an exception. So here are the second flow, I don't have any error handling, what will happen. So if a flow does not have any error handler, the default error handler will be executed. There is a mule default error handler which is global and in visit if in your flow, if you don't have any error handler, then mules default global error handler will be executed. What will do is it will stop the execution of the flow and logs information about the error.

So this is implicit and we cannot configure it. Okay. Now let me run this and see what happens. Okay, it got deployed. And now let us make a request to slash error using postman. I'm getting a request to slash error, but I'm not passing any query parameter as expected.

If you see the second flow, it's expecting a query parameter called us product name, which would be either HP or Mac. Okay. So I'm not passing any query parameter at all. Now let's see. I'll give a request. Give a get request.

So, I got a response invalid product name and I got 500 error why I got this invalid product name. If you see here the the message error message which is thrown by validate component is true validator is invalid product name and I got 500 status code Exam Success 500 is server side error right. So, whenever an exception is thrown by this flow validated transform flow here there is no error handler. So, what happens if there is no error handler subsequent subsequent process will not be executed and then the error will be higher data by directly will propagate it to the main flow from the main flow we're calling right and here also we are not having any error handling. So, there is no error handler the mules default error handler will be executed and it stops the flow execution and logs information about the error. So, error object contains two properties, error description and error type.

See here for for Easter validator, the error options here configured the error messages. Invalid product name why this error message was displayed sexually if you see in HTTP listener, configuration There is a tab called as responses in responses there is something called as error response, see success responses configures payload you can see just click on this success is configured as payload and error response. Let us see what is configured as Oh, it is configured as error dot description. So, as I told you, whenever error occurs, error object is thrown, the error contains two properties error under description and error error. So, the error handler of HTTP listener is actually setting the payload as response bodies error dot description that's why we got error under description. Here, but the status code if you see it is not configured.

It is not configured here for error response. By default, if you don't configure anything, it will be 500 if there is any error, now I'll make a small change in the HTTP listener. Here I'll make it as output as application slash Jason and here I will write error dot. What is the other parameter in the error, error type. There are other properties also like error cause error, description, detailed description etc. Error dot error type error rate, okay.

So I configure it as a Jason. Let us see how it will be displayed. Let me do a request again. I saved it hopefully the application should have been restarted. Yes, it's getting restarted. Yep restarted.

Now I'll give a request. See the response What are we getting? See the responses that Jason which is interesting is a Jason and here you can understand what is the error type. Every error type will have two things namespace and identifier. so here we can see that the error which was propagated was invalid, Boolean, and belong to namespace called us validation. For this error type, the parent is another type who was identified as validation and namespaces were For this again, the parent is another type who's identify as validation belonging to namespace.

Again for this error type, the parent is this one who's identifies any and namespaces. And for this error type, there is no parent. So basically you understood that error types has some hierarchy, I'll just show you your colony, you can see mule namespace colon any is highest one under that there are a lot of sub tests and these subtypes also can have other subtypes right, this is a error type hierarchy. So, when error type is displayed as Jason, you can you are seeing this kind of hierarchy. Jason right. So every error object has these important properties.

Error description and error duck price so what are other sub they're in error object let us see I will go to responses again and maximize it. Here I click on graphical view ref dot the error that cause error description is nothing but our error message error type is what we display right as JSON. Okay to summarize Now, whenever exception occurs in any one of the flow, then in the flow if there are any hand error handlers defined, the processes even process in the error handler will be executed. But, if there is no error handler, new default error handler is executed, which will implicitly handle all the error messages. What is global error handler will do to stop the execution of the flow and logs information okay. You also understood that an error object is created and thrown error object contains these important properties error description, error type.

So, error types are identified by a combination of namespace and an identifier these are an example, these are the examples of error types and we understood that there is a hierarchy for error types. In this example here you can see this JSON represent an error type whose identifier is invalid Boolean belongs to namespace validation. And for this apparent is another type whose identifier is validation belonging to namespace validation. For this again the payment is an error type whose identifier is validation belong to Union face and again for this the parent is error type whose identifier is any and belong to namespace. So, like that every error has a hierarchy and this is how the errors can be classified errors can be classified into two types first is any and others critical. So, what are on the left side under any can be handled, we can actually write error and look for handling any of these errors, but the ones on the right side which are subtypes critical cannot be handled.

So, example of critical error types might be like memory out of out of memory error, etc. Right. So, by default if you're having an HTTP flow by default if there are no exception Success score will we return success response code? If there is error 500 will be written. And error description will be the payload. So we saw in HTTP listener, we configured actually error responses in the error responses, I give.

Error type by default is error dot description. And if you don't if, if you don't define any error response status code, by default, it will be 500. That's what we saw here. Right? If you want to modify Of course, you can go to the responses tab of HTTP endpoint and you can configure whatever status code you feel like. So, in the next video, we'll see how to handle errors by using error handling scopes.

Two types of error handling scopes on error propagate and on error, continue. We'll see that in next video.