How to properly throw an Exception in BPM

jhecker · July 22, 2022, 6:34pm

I have some custom code that runs in a Pre-Processing BPM. That code does some work and will set the value of a variable to either true or false.
When the code is done running, there is a condition check to see if that variable is true. If it is true it branches off and throws an exception. But, I get 2 boxes that appear. This happens if I throw the exception using the BPM designer, and if I do it in a custom code block.

First Box:

Second Box

I don’t know if this is normal behavior or not and I was wondering if anyone here can chime in.

jtownsend · July 22, 2022, 6:54pm

The first error is a rather generic one…is the variable you pass into the BPM even populated yet? Could you post your code?

I’ll also add that there isn’t really one way to throw an error in a BPM. Each module works a little differently. I even have one process that deliberately throws two errors simply because I needed to put a BPM on two different methods (the process didn’t entirely halt at the first exception and there wasn’t any single point upstream where I could have placed a single error either).

tkoch · July 23, 2022, 3:03am

There is no need to set a variable and then check it to throw an exception. In your bpm code use this instead

throw new BLException(“error message”);

timshuwy · July 23, 2022, 4:42am

@tkoch Yes you are very correct, BUT… putting the BLException in the code hides the fact that there could be an error thrown by the BPM. I personally prefer to do as the example that @jhecker provided - creating an error string, and then checking and throwing the error with the widget. Note that when you throw an error message in the C# code, it also terminates the balance of the BPM and this is also hidden…
Doing the error in the widget also allows you to do additional things. For example, I might assemble a larger “errorMessage” or a “deBugMessage” and then make a decision as to whether to throw an error or simply display the message. ALSO I ALWAYS add a test to the bottom of the message that specifies that this came from a BPM and which BPM it came from. This is easily done with the error message widget, as you can simply add that to the end of whatever error message came from your code.

jhecker · July 25, 2022, 11:04am

@jtownsend - for the purposes of this discussion, the code block is this:

Short, sweet, and to the point. Then, in the Condition, I am checking to see if stopProcessing is true, then throw the exception.

Conditional Test:

Exception Template:

That is when I get 2 exception windows displayed (one after the other).
Exception #1:

Exception #2:

And just to be sure that there wasn’t something else interfering, I removed the link from the Conditional block to the Raise Exception block, and tested it. No exceptions were thrown. I put the link back in place, and I get 2 exceptions.

jhecker · July 25, 2022, 12:57pm

For what it is worth, I also get the same issue (2 Exception messages) if I do a:

throw new Ice.BLException(“Message”);

from within the code block. (that is with deleting the “Raise Exception” block from the flow diagram as well)

timshuwy · July 25, 2022, 1:26pm

this looks like something happening because one business object (issue material) is calling another (create lots) and your error message happens during the create lots, which is then crashing out the issue material object… I have not seen this happen before, but it might explain what is going on… if you do the same logic against the ABC Code table, i think you will only see one error.

jhecker · July 25, 2022, 1:51pm

I am not creating any lots with Erp.IssueReturn.OnChangeLotNum. This is being called on the Issue Material screen when a user enters/searches for the Material Lot Number to issue to a job.

Erp.IssueReturn.OnChangeLotNum is called when a value is entered into the LotNum field of the Issue Material screen.

That is when I take over in the BPM by setting stopProcessing to true and checking it with a conditional block right after.

Unless I am misunderstanding the Issue Material screen, there are no lots being created, only searched for or keyed in.

hkeric.wci · July 25, 2022, 2:59pm

You may be best off handling your Exceptions in the Update PRE Method.

You are doing everything right, but sometimes the UI’s need to play nice as well and in this case this specific event isn’t. I usually avoid OnChange Exceptions because the methods often aren’t meant to be interrupted.

jhecker · July 26, 2022, 10:46am

Unfortunately, there is no update method for Erp.IssueReturn. The closest thing I was able to find was/is the OnChangeLotNum, which is triggering exactly where I need it to.

It’s good to know that I am not crazy and am handling this properly. I was afraid for a while that I am overlooking something so obnoxiously simple that it was driving me crazy

But, back to the unfortunate side of things, I am still stuck with both of the exception windows being displayed. That is one sure-fire way to make sure my end users stay annoyed, heh.

EDIT: I am looking through the trace logs to see if there is any other event that triggers during the process, and the only other method that triggers is Erp.Proxy.BO.LotSelectUpdate.GetList, which only fires when the search box is initially displayed. As the lot number will rarely be searched for, it would not work in this instance.
Is there any other method of halting/stopping a Pre-Processing BPM other than with an Exception?