Throwing Exception in a Function

This is more of an observation so hopefully this can help someone if they run across a similar scenario.
I’d bet this is already known by some, apologies if this is common knowledge.

I needed to throw an exception in a Function if a condition was met. In addition to the exception being thrown, I wanted to pass a message back to the calling application to give it some context as to why the exception is being thrown. I also wanted the exception to return a “400” type error to the calling app.

In this case, I have an string output variable that stores the message back from the function.
Using the “Raise Exception” Widget in my function did indeed raise an exception, but I could not get it to send an output message other than the default “something went wrong” message, regardless of what I set my exception message to be.
I did try setting my output variable prior to the exception in his screenshot as well…

A postman call to that function to trigger the exception then shows this generic message (with a 400 error, thankfully)

In order to give it some context however, I found a custom code widget was a good way to both throw a 400 exception and display a custom message back to the calling app

Thanks for coming to my TED talk

1 Like

in your web config for the app server turn off customerrors.


Then if you do throw new Ice.BLException(“my message”); it will show up in the log and response

2 Likes

In 10.2.500+ it works without custom code :slight_smile:

1 Like

As usual, I think I’m the last to know :slight_smile: Thank you!

Does this just require an IIS recycle to get it going? Good to know though I think I’ll go this route

it will restart app server for you because you edit web.config

But this approach is not recommended because all exceptions will be shown by IIS with this flag.

ooo, so in this particular use case, I might be better off using the custom code approach?

yes, this is better from security POV

2 Likes

@Olga if you don’t turn off custom errors how do you get native errors for say field validation out of the REST API? Example a missing required field or something?

Monitoring is one of the DevOps steps I’d like to see added to the development flow. In the future I’d like to see errors logged to a safe place (for me Azure or AWS) where devs, including those working with SaaS versions of Epicor, can get to these types of errors easily as well as notifying local and Epicor devs of errors in the system without user interaction.

1 Like

At the beginning, custom errors were the only way.
But later the exception types started to be used for this purpose.
Look into REST API Exceptions section in the REST documentation.
For example,
Ice.Common.BusinessObjectException (and derived, like BLException)
means Error in business logic and returns 400 - Bad request with error message in response

2 Likes

We’ll look into that deeper when refitting our nuget library for 2.0. Would that return object include anything we throw ourselves from say a BAQ or Function as a Ice.BLException? I believe those come back as 500s not 400s unless that’s part of the change that’s been made in the response types

1 Like

You can derive your own type, if it suits you.
there is special flag to mark exception to show on the client:

|EpicorTemplateExceptionBase (and derived)|400 - Bad request|An error happened during processing. Exception will be visible on the client if it is marked as Visible in the application code:

EpicorTemplateExceptionBase.Classification == ExceptionClassification.Public

or use Ice.Common.BusinessObjectException (and derived, like BLException) as suggested in the first message of this topic

1 Like

also all this exception handling was done in 10.2.200.
I think the BPM exception action was changed in 10.2.500

Thanks for the info on that. @josecgomez and I were discussing on the side how to make the REST Nuget backwards compatible in the best way possible. So knowing those milestones helps.

1 Like