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…
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
@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.
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
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
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:
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.
