I have built a custom package which generates some values and send emails as per business requirement. I have also handled business exceptions by using throw/rethrow activity when a valid value is not provided by developer. It is working fine in dev.
But when I run it through orchestrator it runs peacefully until there is no exception, as soon as exception comes like business the activity built gets faulted.
I dont know why it is getting faulted even when the exception is handled in Try catch. Also in Try catch I have used purposely Rethrow and throw so that the error comes out.
Any solutions why the package activity is getting faulted anyone??
Unhandled Exceptions: Ensure that there are no unhandled exceptions within your workflow. Even though you have a Try-Catch block, there might be an exception that is not caught. Make sure that all possible exceptions are covered within the Try-Catch block.
Exception Type Mismatch: Verify that the exception type you are catching in the Catch block matches the actual exception that is being thrown. If the exception types don’t match, the Catch block won’t be executed, and the exception will propagate up the call stack.
Re-Throwing Exceptions: When you use the “Rethrow” activity within a Catch block, it re-throws the exception, which means it will be caught by an outer Try-Catch or, if there isn’t one, the workflow will be marked as faulted in Orchestrator. Check the behavior of “Rethrow” activities in your workflow and make sure they are used appropriately.
Debugging: If you are unable to identify the issue, consider using Orchestrator’s debugging capabilities. You can enable debugging for a specific job to step through the workflow and diagnose where the fault occurs
If exception is being thrown from a child activity., it will bubble up to the parent activity and cause the parent activity to fault, even if the parent activity has Try/Catch handling.
That is…
Though the exceptions are captured with try catch and thrown further with throw or ReThrow, that thrown exception should be still captured or handled with another TRY CATCH
Make sure you have done that
Say you have a sequence surround by a try catch
If anything goes wrong exception will be caught by try catch activity and if u r throwing that again with ReThrow in catch block it has to be captured and handled. If not it will stop the bot with that thrown exception
So when you rethrow or throw a custom exception, it can affect the behavior of your workflow, especially when running in Orchestrator. Double-check that your custom exception types are properly defined and handled.
Perform some troubleshooting steps or debug the code and understand where code tweaks are needed
Check the logs to see what exception is being thrown.
If the exception is being thrown from a child activity, try moving the Try/Catch handling to the parent activity.
So if I remove the the try catch block will it work fine?
Ex. there is an argument named In_Str_OutlookFolder now if this is blank I am throwing New BusinessRuleException(“Argument blank”) like this and this was inside a try catch which was again throwing it out side when bot is going faulted in Orch… So now if I remove the try catch and then just use the first throw for outlook argument will it work?
If you remove the try/catch block around the Throw New BusinessRuleException("Argument blank") statement, the bot will fault if the In_Str_OutlookFolder argument is blank. This is because the exception will not be handled and will bubble up to the parent activity.
Whether or not this is the desired behavior depends on your specific needs. If you want the bot to fault if the In_Str_OutlookFolder argument is blank, then you can remove the try/catch block. However, if you want the bot to continue processing even if the In_Str_OutlookFolder argument is blank, then you should keep the try/catch block and handle the exception inside the catch block.
If you are unsure, it is best to keep the try/catch block and handle the exception inside the catch block. This will prevent the bot from faulting and will allow you to control how the exception is handled.
In summary, removing the try-catch block and using a simple throw statement is acceptable as long as you have a well-defined strategy for handling and reporting exceptions.
Also, I done want the activity to get fault as this is a custom activity what I have made which others will use I want that if any argument is blank activity should throw exception/should inform them that I cannot run because this argument you have left blank kindly fill in required value. How should I handle this?
Have a validation inolace before trying process it
Like a if condition to validate whether the in argument is null or not
If null then throw a message or continue further
So you are suggesting, I should not use throw/rethrow it will fault the job instead I should use log message something like this to log an error or warning?
Let me make it clear
If you are unsure about exception, it is best to keep the try/catch block and handle the exception inside the catch block. This will prevent the bot from faulting
To handle it even better like if u r not sure at which place the error would then try introducing global exception handler which can handle exception that occurs any where in the process and let the bot to continue or break as we need
Check this out for more insights
And on this
As I suggested have a IF condition and validate the in argument before processing it