Additional information: when an explicit error is thrown in the OnAfterResponse (like in the example above), or when a non-200-series status code is received (like a "403 forbidden"), the Error Log always shows the Exception, with Module "REST (Consume)". Since these kind of Exceptions or status codes are expected, and are handled in the Action that calls the REST API Method (where the developer can choose to log an error or not in the Exception Handler), these messages pollute the Error Log, and should imho simply not be there (note that if they are not handled by the caller, two exception messages are logged, which is a bit superfluous anyway).

I'm facing the exact same problem.

The API that I'm using sends a status code 404 when they don't have information but for me, that's not an error. I just want to handle it differently from the status code 200 and not log the error. 

Right now I have service center filled with this 404 errors and I cannot easily identify the "real" errors of my factory.

Hi Patrícia, 

Thanks for your feedback.

On your code if you don't throw the exception and just replace it by an End node, it will not be logged on Service Center.

If you wish to throw the exception and not log in service center you can catch the exception and choose the property Log Error set No.

Thanks,

Hi Fernando,

I encourage you to do the test yourself and see that it will log the error even with the property Log Error set No. 

I've tested this In version 10 and the only way I have for the platform not to log it as an error is to change the status code to '200' 

Hi Fernando,

Like Ricardo, I've also tested what you suggested (with expose APIs) and didn't work. 

Additionally, the solution you presented only applies to expose API where my problem was with consuming APIs.  

Either way, it doesn't work if I don't change the status code to '200' like Ricardo said which in my case is not possible since I want to handle the exception in another scope. 

Thanks for enlightenment, now I do understand the use case. 

What would be reason for not logging the error?

On Ricardo use case, the REST integration returns 404 when there is not information. But I guess, we all agree this is not a common or even best practice. With this kind of approach the consumer doesn't know if the service is down or was because there is no record to return. 

We should avoid this patterns and enforce good practices that allow our applications to be robust and provide accurate information to our users.

Patricia what is your use case for not wanting to have the log?

I would say returning a 404 on resource not found is the standard way to report this back, though "no information" is different from "resource not found", so perhaps you have something different in mind? Regardless, the way that the Platform currently handles error codes (both consuming and producing) is way under par, but that's for a different topic...

I'm facing the same problem I am catching an 403 error in an IS module and throwing an exception there and catching that exception in a CS module. It works, it is just that the exception is being logged and it is filling the log tables quickly, as it is shown in the Exception Handler's property Log Error should avoid this to happen but it is not doing that.
What I mean is I want to use exceptions to propagate the error up the hierarchy, I just don't want to see the log of that exception.

Could someone bring this back  "in scope" in stead of "out of scope".... Return values for REST api's are very common AND best practice to catch and handle. Now i have to use an onafterresponse to set the code to 200 and not log the message. ANd then in the calling action try to figure out what happened. We consume a lot of API's where the method contains a parameter IN the url (so not as url parameter). A 404 is then a perfectly normal response. For instance: https://......./api/1/books/2013532 .... THe api endpoint is then defined by /books/{BookId} . This should give a 404 if the book with id 2013532 is not found. No way now to handle this the way you can.... Catch the error in a server action in the integrations module and handle that logic from there..... We only have the GENERIC onafterrespons where we can sort of guess wwhat to do...

ps.. LIKE!