| Author |
Message
|
| Harman |
 Posted: Fri Oct 23, 2020 3:28 am Post subject: Error Handling using nested try catch nodes |
 |
|
Newbie
Joined: 22 Apr 2020
Posts: 9
|
Hi
Currently , my flows looks like
Subflow 1 : Input -> TryCatch -> Subflow2 -> Output
Subflow 2 : Input -> TryCatch -> HTTP -> Output
What is happening in my scenario is ,when HTTP results in 500 , the catch block in the Subflow2 handles the exception gracefully and the control goes to the Subflow1 .
Now the compute node in Subflow1 throws user exception, the control goes back to the Subflow2 in the catch block.
But I dont want this to happen , I want the user exception thrown in Subflow1 should be handled by the tryCatch in Subflow1 and not Subflow2 .
Please suggest if there is any way to achieve this scenario |
|
| Back to top |
|
 |
| Vitor |
| Posted: Fri Oct 23, 2020 4:53 am Post subject: Re: Error Handling using nested try catch nodes |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Harman wrote: |
| Now the compute node in Subflow1 throws user exception, the control goes back to the Subflow2 in the catch block. |
Where's the compute note in Subflow1? Before or after the try/catch? Before or after Subflow2?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Harman |
| Posted: Fri Oct 23, 2020 5:02 am Post subject: |
|
|
Newbie
Joined: 22 Apr 2020
Posts: 9
|
| @Vitor the compute node which may throw user exception is immediately after the Subflow2 . |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Oct 23, 2020 7:26 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Functioning as designed I'm afraid.
One possible solution would be for Subflow2 to rethrow any exceptions that are not HTTP related.
Someone will be along in a minute with a better solution.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| abhi_thri |
| Posted: Wed Oct 28, 2020 11:39 pm Post subject: |
|
|
Knight
Joined: 17 Jul 2017
Posts: 516
Location: UK
|
hi...As Vitor mentioned it is working as designed. Usually you are better off using a generic error handling logic (eg:- using a error subflow(s)) at a message flow level by connecting it to the Catch terminal of the input node. This allows you to build a consistent error handling framework across all your interfaces which can be changed/improved without modifying any functional interface specific logic.
Where specific error handling is required, eg:- inspecting Http/Soap errors you can add node specific error logic (eg:- for HttpRequest, SoapRequest nodes etc) by connecting the fault/failure terminals of the nodes to a common node/subflow.
This ensures that scenarios where extra error handling is requried are dealt there and then and all the remaining runtime or other errors across the interface is dealt by the default error framework.
When it comes to error handling it is always advisable to keep it simple where possible which allows you to reap the benefit in the long run. |
|
| Back to top |
|
|
| Harman |
| Posted: Thu Oct 29, 2020 4:52 am Post subject: |
|
|
Newbie
Joined: 22 Apr 2020
Posts: 9
|
| Thank you @Vitor and @abhi_thri for your valuable inputs . |
|
| Back to top |
|
|
|
|
