I’m using the REFramework and trying to bubble up an exception from like 2 levels down back up to the Try Catch in the Process Transaction state so that the program can just continue on with the next transaction. However, the exception that I’m throwing inside this sub-sub-workflow is just stopping the entire program.
As comes standard, the Process Transaction state contains the Try Catch, where the Try invokes Process.xaml and one of the Catches is for a BusinessRuleException. In Process.xaml I invoke workflow1 (which is a flowchart), which in turn invokes workflow2, which contans a Throw activity for a New BusinessRuleException. More schematically,
Process Transaction > Try: Invoke Process.xaml; Catch: BusinessRuleException
The REFramework is not catching this two-level-deep exception even though it is the only Try Catch in that chain as far as I can tell. According to replies like this one, if there are no Try Catches in the way, the exception should bubble up automatically, but that doesn’t seem to be happening in my program.
I seem to be able to bubble it up by wrapping these inner workflows with Try Catches all the way up but it seems messy and not a best practice. I’ve also seen mentions of using Rethrow to bubble it up but I think that requires the same wrapping with Try Catches and multiple levels.
EDIT: To test it out, I’ve even tried putting a Throw activity as the very first thing inside Process.xaml and yet the Try Catch in the parent ProcessTransaction state does not catch it. The exception just stops my program.
EDIT 2: I’m actually noticing that if the Throw activity is inside a sequence or a workflow, it does not get caught. Only a single, naked Throw triggers the Catch. For example, this works:
ProcessTransaction state > Try: Throw
These don’t work:
ProcessTransaction state > Try: Sequence > Throw
ProcessTransaction state > Try: Invoke ThrowWorkflow > Sequence > Throw
Final EDIT: This answer made me realize that the Try Catch doesn’t work as I expected when running in debug mode. If you run it normally, it works. Does anybody know why this is?
I think in Debug, you are trying to troubleshoot why it’s going to the Catch in the first place, which technically should only happen when an error occurs, and you are trying to solve the error while in Debug mode so it stops you. I suppose this would make testing error handling tricky… but like for myself, I never use Debug mode and always use Run mode while testing and debugging; maybe the new features in 2019 will make debug mode more easier though.
I have never seen this ever. I suspect there might be something else causing this. Note: just for less clutter you should remove any sequences that only contain 1 activity, for example an IF that only has a Throw should not have a Sequence with a Throw in it and you should cut out the Sequence. But, like I said, this shouldn’t cause any problems with the code.
I would also suggest that you leave error catching to the outermost code block or state. When you start catching errors inside of workflows and inside of workflows inside of those workflows, it all becomes very redundant. A better practice is to check for certain elements or text to exist, then Throw the App Exception or BusinessRule Exception, for the Main to catch and attempt a retry or continue to next item. But, I’m also open to thinking outside of that box to explore possibly better methodologies.