So I have this issue where a certain node at the beginning of my loop sometimes runs into an error. I just needs to be refreshed at that point and it will work. However I want KNIME to do this for me. I looked at the TRY-CATCH nodes but didn’t get it to work.
My situation looks like this below. The node with the issue is “Navigate”. What nodes do I require to relaunch the navigate node incase it gives an error?
Hi @Sjoerd , can you show us how you used the TRY-CATCH nodes? The 2 options that @mlauber71 suggested both use TRY-CATCH. I’m trying to see if you actually get an error or not. If you don’t get any error per se, you will not be able to use TRY-CATCH.
I’m not familiar with the Navigate node - it looks to be part of the Selenium package. I understand what it does, but I’ve never used it, so I don’t know its behaviour.
The navigate step simply refreshes a webpage. In some cases the refreshing fails and it ends in an error (due to slow internet for example).
When I add the try node in front of it, it doesnt work because of the loop that it is in apparently. Basically I dont really know how to start with the usage of the try node in combination with the loop…
Just like with a Try-Catch construct in programming, your nodes that might fail need to be sandwiched between a Try and a Catch node. The Catch node also requires an alternative input that it passes downstream when the normal branch failed:
That alone won’t fix your problem though, because you absolutely need the Navigate node to be executed?
Here’s what I came up with. It’s a bit whacky, maybe there’s a better solution for this:
Your Navigate node needs to be put into a Try-Catch construct, so the workflow won’t break. That will not retry its execution though. I used a Generic Loop Start for that: It will iterate over the input table until at the Variable Loop End a condition is met. In this case, the loop ends when the Navigate node did not fail. Additionally, there’s a metanode that waits 2 seconds if the Navigate node failed, since you might not want to hit a webserver a bazillion times each second. It will also stop after a certain number of attempts, as you probably want to give up at some point.
The most tricky part was to find out when the primary branch of the Try-Catch failed, because the related error flow variables won’t exist upon success. I realised I could use a Table Difference Finder and compare it with the fallback table. If they’re the same, we have a fail.
For future people:
I just tried using Ana’s approach to detecting errors in a Try-Catch block and it didn’t work, because the Rule Engine doesn’t like nonexisting variables. I even tried to trick it by copying a configured rule engine over, but to no avail, I have to use my jerry rigged solution.
Maybe this could be a feature: Always populate a Flow Variable with the info whether or not the Catch got triggered?