Exception Handling in Reframework - Correct Strategy

[AnkitJain]

Hi

To give a back ground, before I move ahead.:
In Process State, I have transaction item as Email. So basically, in process.xaml, I am downloading attachments in a folder. And then one by one each attachment file is uploaded in some application. And once it is done then some updates (sort of data entry ) is done in two other windows in the same application, with this work for a transaction item is over.

Now there are lot of workflows added in Process.Xaml…

So if Process.XAML is Parent, there are workflow which are Child1, Child2, and Then within Child 2, I have Grandchild 1, Grand Child2, Grand Child3 workflow.

Process State itself has a Try Catch block.

Question

1. Suppose in any of the Child or Grand Child workflow if there is any exception (system exception, say let us say when a window is not responding or a button becomes unresponsive even after the wait time), so will the outer most Parent Try Catch block will still be able to capture it.

I saw it, that a error was notified in Output panel, and probably since it was System Exception, so it Closed applications and restarted the process. Is my understanding correct ?

2. If say for any reason I “Throw” a Business exception in Grand Child, will stil the Parent Try Catch be able to capture it, and will move the control to next Transaction item.

3. When should I use Try and Catch again in the Child or Grand Child workflows, is it required ?

4. When should a Re-throw be required

Your guidance will help me to clear my confusion.

Regards
Ankit

[Jeroen_van_Loon]

1. Yes. In this order:

• It will check if there is a global exception handler first
• It will look for the inner most exceptionhandler from the nested workflow
• then move to the outer ones
  thisuntill the error is captured somewhere. So in your case the error handler in the process state will capture the error of your ‘grandchild’ sequences.

Ref will send a system exception back to the init as a state transition. There it will indeed close all applications and reopen them, assuming you populated those features.
A business exception will return directly to getting the next queueitem, so you’ll have to handle any UI resets yourself there.

2. yes, a business exception is a type of exception which is capturable by the error handler. In ref it returns to fetching the next transaction item.

3. Depends on what you want to achieve. My philosophy is that if you want behaviour that is different than your outer error handler for specific cases, then use an inner handler. Otherwise rely on the outer handler as much as possible.

4. Rethrow is a good use when using inner exception handlers. Lets say your grandchild has it’s own try catch to see if a download succeeds by checking a system exception. You catch it, log something, maybe send a mail or whatever. After this you still want the outer error handler to wrap up things. By rethrowing the error it re-occurs and can be cought again by a second error handler. (your outer handler)

[AnkitJain]

Thanks a lot, this answers my queries.

Additonal question, suppose I want to move transaction item(email in mycase) to a folder, but when Business exception occurs, and send an email notification when any other exception occurs in child or grand child workflows.
So to do this, in the parent try catch, within “Catch” should I add two exceptions:

1. BusinessException (and then inside it add move email activity)
2. SystemException (and inside it add send email activity)

Please confirm.
One additional question, just for instance, if I leave default exception in “Catch” block , will it still catch Business exception ?
Thanks

[Jeroen_van_Loon]

If you have multiple exception types in one error handler, it first catches the most specific error. In this case a business exception is more specific…

And yes:confirmed, you can add different behaviours to different exceptions as you described.

If you would throw/rethrow a business exception, and the receiving error handler does not have a catch for a bus exception, it will still treat is as a system exception.

Since system.exception can be considered the most generic exception, it is best to have at least one catch for this type in your outer most handler. This way you ensure that there is a guaranteed catch, even if inner handlers are not complete enough. REF already has this built in, so unless you want specificly tailored errorhandling, using REF takes care of most of this automatically.