I am struggling a lot with Try-Catch Error nodes. I just want to pass the input of the first variable port if the execution of the top branch is ok, as the node description states :
This node forwards the input from the first port if the execution wassuccessful. If execution on the top branch failed (and a matching trynode was connected before the failing node!) then the input from thesecond port will be forwarded and the second variable outport will containinformation about the observed error.
default variable = 0
alternative = 1
Catch Errors node outputs are (output and failure) perfectly identical :
So the _error_caught is always 0 and the switch is moving always to the above port, making Try-Catch useless.
Why the propagated variable value is always the same - the variable value propagated through the top branch - even if the top branch fails ??? Am I missing something or it’s a Knime (4.5.1) bug ?
I know there could be workarounds but I am really interested in understanding why it is not working according to Knime official description.
Please, do not suggest me further examples/documentations (I already try that way).
Many Thanks !
Hi and welcome to the forum!
It’d help if you shared the configuration you have for the Catch Errors (Var Ports) node as the behavior depends on if you have Propagate Variables selected. That said, this behavior only shows up when a flow variable of the same name and type are defined but differ between the try and catch block.
Without Propagate Variables it comes down to which variable was defined first as to which value is passed downstream, such as the case in your workflow using the default value.
With Propagate Variables if they are define or modified, such as when the input is used when the main branch fails, they are carried downstream as well.
I know you asked for no more examples but I’ve attached a workflow below if you want to test these concepts of flow variable precedence and propagation.
Forum Try - Catch.knwf (49.0 KB)
Hi @nfriesen, and thanks a lot for your answer!
I tried the workflow you shared but I am still finding Catch Errors (variable ports) particularly senseless, because :
With variable_1 there, the Catch Errors node does what expected, ok !
Without variable_1 there, _error_caught variable is = 0 till Table Validator node, where by magic it becomes 1
So the value of 1, needed for a correct switch, it’s not produced by the alternative table (Variable Creator node where _error_caught variable = 1)
I found a workaround (I will share it) but still would like to understand what the usefulness of the below data port and how ans why _error_caught transformed itself from 0 to 1 without reason.
Many thanks for your attention and availability
I see, I had assumed you had created the variable _error_caught and were managing it yourself which is what I replicated in my workflow.
As I’ve found out
_error_caught is only created when the top branch of the scope fails. Thus the flow variable
_error_caught is set at the same time as the rest of the error flow variables are set which is on the failed node (which you’ve noticed on the Table Validator node since it doesn’t rely on the Variable creator to update the flow variable). However, if there is a component that fails in the scope of the try-catch this variable isn’t set which is indeed a known bug and in my testing persists as of AP 4.7.0
I’ll update the ticket (AP-18714) for this. If you can, please share the workaround you found as well here in this thread.
Thanks in advance,
Yeah, you are right. Unfortunately there is still this annoying bug.
Let’s hope that it will be fixed sooner than later.
Hi @nfriesen and @Luca_Italy,
Thank you for your answers and here my workaround :
As some variables are always passed, despite the branch failed or not :
I can use one of them (let’s take “FailingNode”) fof creating the switch conditions with a rule engine node :
At this point, variable creator node should be no longer needed, but without the alternative one Catch Error does not work.
Hope it will help others who are dealing with the same bug !
The very same approach used by myself.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.