Ideas for flexible Exception handlers within API's

Hi everyone,

We are working on a web application which we try to build as reusable as possible. Therefore we also expose a lot of our actions with REST. Tho we would like to make something for exceptions, an action or something which we can drag into REST-methods or CRUD-actions to make it work. Has anyone ever done something like this before?

Cheers!

Hi, Roemer,

Sorry, but what exactly is the behaviour you are looking for?
Could you give an example?

Cheers.

Eduardo Jauch wrote:

Hi, Roemer,

Sorry, but what exactly is the behaviour you are looking for?
Could you give an example?

Cheers.

Right, we got around 15 entities for which we all created CRUD actions, which are used in REST-methods. Tho now we are looking into exception management. The easiest way is to just copy and paste every exception handler in every CRUD action. But I was wondering if it is possible to build one action which can handle all exceptions? So if we want to alter the messages for example, we only have to change it in one place! 


Hello Roemer, 

I think that you can create an action that receives the error and raise the exception. And you can use it all the time in the "On after response" for each rest api. 

This helps?

Hi Roemer,

If I understood correctly, I don't know how to do what you want, or if it is possible.

When you expose a REST API method, and this method calls a Server Action (your wrapper action), if your action raises an exception that is not caught in the wrapper or in the exposed method, it will be caught internally. It will not bubble up to the OnException of the module like it does when you call the Server Action from a Screen Action without exception handlers on both. This means that you can't have a central point where you could catch all the exceptions from different actions if you are calling from the REST API.

If you add an OnRequest action to the service, it will be triggered before the exception raises.

If you add an OnResponse action to the service, it will be triggered after the exception raises. It will try to return an error 500 and you can, of course, adapt the returned code, but the exception was already logged in the database.

In fact, if your concern is to log the exception, then you don't have a problem, as the exception will be logged anyway, even if the wrappers do not have exception handlers (if called from the REST API).

If you want to customize the exception log message or the returned code then it seems you have to add an Exception Handler for each wrapper, or at least to the API methods.

I'll try to see with some experts if there is any way to work around this, but I don't have too much hope...

Let me know if I understood wrongly your request.

Cheers.

Hi Roemer,


I understood same as Eduardo, and agree entirely with his comment.  

The problem is that we don't have the exception object available for use in expressions inside the exception handler (like in other languages, where you can have a general handler catching all exceptions, but the exception is passed into it as a parameter, so inside you can add further logic to act differently based on type of exception.

The only thing we have available is the message, like so :


I would like to see a record in that spot, holding all information about the exception, and also the ability to assign it to variables / input parameters.


But dealing with what we have right now, I made a small example project exploring what you could do :

On the API exposer side :

all api methods follow same template, no real (business) logic in here, only thing different between them is inputs, outputs, and the dba action that is called

all api methods share same output structure holding a message and a message type.

All the 'Handle...' actions in here are calls to one and the same handler.

all real logic is inside database actions (name starting with dba) that are called from api method

2 utility actions supporting the api

one for logging in, this is just example for testing, is not a secure way of doing this !

other for handling exceptions being raised, translating them into an appropriate message and message type, and anything else that you would want to do with the exception



On the API consumer side :


A common Action is called after every api call, translating the message and messagetype coming from the api, into a feedback message.  This is expandable with more decision logic, or maybe some logging...


See attached zip with 2 oml's in it, the 'producer' exposing the api, and the 'consumer' calling the api.  I hope it's clear what I'm trying to achieve with this, i would love your comments.

Dorine

Eduardo Jauch wrote:

Hi Roemer,

If I understood correctly, I don't know how to do what you want, or if it is possible.

When you expose a REST API method, and this method calls a Server Action (your wrapper action), if your action raises an exception that is not caught in the wrapper or in the exposed method, it will be caught internally. It will not bubble up to the OnException of the module like it does when you call the Server Action from a Screen Action without exception handlers on both. This means that you can't have a central point where you could catch all the exceptions from different actions if you are calling from the REST API.

If you add an OnRequest action to the service, it will be triggered before the exception raises.

If you add an OnResponse action to the service, it will be triggered after the exception raises. It will try to return an error 500 and you can, of course, adapt the returned code, but the exception was already logged in the database.

In fact, if your concern is to log the exception, then you don't have a problem, as the exception will be logged anyway, even if the wrappers do not have exception handlers (if called from the REST API).

If you want to customize the exception log message or the returned code then it seems you have to add an Exception Handler for each wrapper, or at least to the API methods.

I'll try to see with some experts if there is any way to work around this, but I don't have too much hope...

Let me know if I understood wrongly your request.

Cheers.

You understood correctly! And thanks for the detailed answer! I was afraid so, at the moment we changed our architecture quite a bit and probably won't have the need for this, tho if you come up with some sort of solution, I would love to hear it since I am quite interested in this!


Dorine Boudry wrote:

Hi Roemer,


I understood same as Eduardo, and agree entirely with his comment.  

The problem is that we don't have the exception object available for use in expressions inside the exception handler (like in other languages, where you can have a general handler catching all exceptions, but the exception is passed into it as a parameter, so inside you can add further logic to act differently based on type of exception.

The only thing we have available is the message, like so :


I would like to see a record in that spot, holding all information about the exception, and also the ability to assign it to variables / input parameters.


But dealing with what we have right now, I made a small example project exploring what you could do :

On the API exposer side :

all api methods follow same template, no real (business) logic in here, only thing different between them is inputs, outputs, and the dba action that is called

all api methods share same output structure holding a message and a message type.

All the 'Handle...' actions in here are calls to one and the same handler.

all real logic is inside database actions (name starting with dba) that are called from api method

2 utility actions supporting the api

one for logging in, this is just example for testing, is not a secure way of doing this !

other for handling exceptions being raised, translating them into an appropriate message and message type, and anything else that you would want to do with the exception



On the API consumer side :


A common Action is called after every api call, translating the message and messagetype coming from the api, into a feedback message.  This is expandable with more decision logic, or maybe some logging...


See attached zip with 2 oml's in it, the 'producer' exposing the api, and the 'consumer' calling the api.  I hope it's clear what I'm trying to achieve with this, i would love your comments.

Dorine

Wow! This is amazing what you did here! We have changed our application a bit tho, but I will try this myself since I think this is quite interesting!