Hi All,
I am trying to see if I can use an exception as an IF condition , something like if the file has an exception then do nothing else continue through the workflow.
Is this do-able ?
Thanks
Hi All,
I am trying to see if I can use an exception as an IF condition , something like if the file has an exception then do nothing else continue through the workflow.
Is this do-able ?
Thanks
One option is to set the activity’s “ContinueOnError” property to True. That will make it keep going if it errors.
Another option is
The “Try/Catch” activity.
You place the activities in the Try section, then add an Exception in the Catch and place activities you want to do if it errors.
If you leave the Catch with no activities it will do nothing and continue.
Thanks. Hope that helps.
Create a variable(string) to catch the exception and assign exception.Tostring to that variable.
After your try catch keep a flow decision variable = string.Empty condition.
Keep your next steps Yes, nothing in No to exit the workflow.
Yes it is do-able.
You can use Try-catch activity and in catch block just handle your exception and then assign that exception in a variable like below:
System.Exception SystemError = exception;
then in If activity you can simply check like this SystemError is Nothing.
Regards…!!
Aksh
I’d advise against that and go with what @aksh1yadav suggested. When using .ToString() you lose access (or make it much harder as you need to parse it from string) to some data (Type comes immediately to mind) and also work against using it higher up in the hierarchy as an inner exception or in general exception handling.
Generalising a bit, I’d say that keeping the objects as their original type as long as feasible would be the best approach and “change” it only when needed (f.e. exception.ToString() is useful for putting it in logs, but not to build logic upon).
As an example:
ArgumentNullException and ArgumentOutOfRangeException are both subtypes of ArgumentException. Depending on what you’re doing, it is feasible to act differently on those or do a catch just for ArgumentException. If you .ToString() your exceptions, that possibility is lost (or made frustrating to do and error prone).