Reference user exception in other module

Hi all,

is there a way to know what exact exception is being raised across module borders ?

Let's say I have a public server action in core module, doing all kinds of stuff and throwing any number of possible exceptions. 

Let's say I have a UI module calling this public server action, and after the call I want to do exception handling, where I want to act differently dependent on the exact exception being thrown.

I know I can make a distinction between the different types like database exception vs. user exception. 

But what if the server action could throw 3 possible User Exceptions, is there a way to know in the UI module which one was thrown.  I can't make them public, so i don't see how.




Hi Dorine,

If the server action could throw 3 possible User Exceptions or any other 3 exceptions like the screen shot below:

In that case we can set the output parameter value and wherever you are handling that exception you can validate that output parameter value to identify it's origin.


Manish Jawla


Hello Dorine,

Hope you're doing well.

"But what if the server action could throw 3 possible User Exceptions, is there a way to know in the UI module which one was thrown.  I can't make them public, so i don't see how."

The only way you can do this is to have different outputs for the server action, depending on the respective User Exception that you're handling. Please check the example:

Back to the UI module, you need to verify the output of your server action and threat it accordingly. This way will allow you to know which exception was thrown and execute a different logic for each one of them.

Kind regards,

Rui Barradas

Thank you Manish and Rui,

So yes, that's what I was afraid of :-(

I'm basically forced to 

- add some sort of error code output parameter to my public server action on producer side

- catch the specific exceptions that I don't want to loose information about in the public server action

- turn each specific user exception into a different value for that extra output parameter

- loose the mechanism of directly going to the correct exception handler on the consumer side, instead I'm forced to write exception handling code (i.e. evaluating that error parameter) smack in the middle of my happy flow

Ok, thanks, I'l think some more about how I want to deal with this in as nice a way as possible.



Hi again Dorine,

Yes, all of your conclusions are correct.

Usually what I use in my applications is a generic (common) structure, specific for error handling purposes that I put as an output parameter of my server actions.

Basically, that structure has some attributes like the type of the error and a description / message of the error.

In my opinion, it's the easiest way to deal with this.

Kind regards,

Rui Barradas

Hi all,

This means that - as far as I know - in the case of User Exceptions we just shouldn't use them and use the old technique of returning error codes from actions and checking them after each action execution (in error handling code we have no access to the output of executed actions).

Does anybody know why User Exceptions cannot be public? Has OS Team explained this? Are there any so deep technical reasons?



Does anybody know if there is any update to this topic? When consuming multiple APIs the easiest way to distinguish which integration the exception came from would be to re-throw the exception as a specific type. Since user exceptions cannot be made public there is no way to achieve this, and we are instead left checking a static entity for error codes to create proper error handling.

Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.