14
Views
6
Comments
Solved
Handling expected error

I have an server action (Action1) which calls an REST API. The API will return a structure containing StatusCode and ErrorMessage.

StatusCode indicates whether the operation in the API was successfully performed (0) or failed (1).

ErrorMessage contains the error message that the operation in the API returned in a failed operation.  

Is it recommended for Action1 to

  • return 2 output parameters (IsSuccess, ErrorMessage) to indicate whether Action1 is successfully performed or
  • throw an exception using ErrorMessage as the exception message
Rank: #1440
Solution

Hi Kaiming,

   1. It would be better if you create a ResponseStatus (static entity) in a common module and return this Status Id instead of returning boolean type.

 

   2.throw exception using ErrorMessage is fine.

Regards,

Zhou Shuai

Rank: #222

Hi Kaiming,


Since it is not a communication or server side error no exception will be throw.

With this in mind if you want to control the success or failure of your service you will have to use your outputs like you commented.


If you want to throw yourself an exception or not I would say will depend on your user case.


I particularly think it is a good practice to wrap you rest call in an action and throw an exception, because in this way, you can take advantage of the service center logs, and the exception flow where you can abort some transaction for example.


But if you don't really need all these things, you could just show a message to the user saying that the service was not successful, it will depend on your user case.


Also see here some practices used to change the code of the request to throw erros like it would throw if was a failure

Hi Kaiming,

You can handle the exception or manipulate the response in this call back.

More details go through below link

https://success.outsystems.com/Documentation/11/Extensibility_and_Integration/REST/Expose_REST_APIs/Customize_REST_API_Responses


Regards

Shashikant Shukla

mvp_badge
MVP
Rank: #18

Hi Kaiming Thia,

Both the approaches you mention are acceptable (and the most common approaches to this scenario) and will mostly depend on your preference or your organization's coding conventions.

This being said, given that an exception handler flow needs to be completely independent of the main action flow, I tend to prefer the boolean Success + text Message approach, where after dealing with both possible outcomes of the call I can continue with any common logic.

Hope this helps!

Rank: #7425

If I were to use output parameters, most of the time I will just display (feedback message) the ErrorMessage of an Action if StatusCode <> 0. 

However, since I am also displaying ExceptionMessage in my global exception handler, I don't see any benefit in returning and checking the output parameters to display ErrorMessage when I can just bubble up to the global exception handler to perform the same thing. If there are any use case which needs more than displaying the message, I can just drop an Exception handler in that particular action to handle.

Rank: #222

Kaiming, if I understand right your last message...

The problem is that OutSystems will only throw an exception if some error with the code, with the communication or something wrong in the server side happens, it will not address your custom validations.


For example, if you have a service that calculates the value of a mathematical expression and, if the value is negative you want to warn your user that something may be wrong, even if the service returned status 200 OK...


For this lets say that you will need a custom output, with some custom error code that is generated by your services Business rules, when you service returns it, you can wrap every call of this service in a server action, to throw a custom exception (That you can catch and treat or not, in your other actions) and this way you will benefit from the OutSystems' logs and exception handling.


Whit all that said, what I consider a good practice is to centralize your service calls in an action, to beyond normalize your return, also handle yours custom erros and messages based in your outputs.

It is easier to maintain