Repository navigation
Do not continue after failures inside TRY blocks in teardowns #4987
Description
When a keyword is ran within a teardown (case or suite) all operations inside a TRY block are executed even if there is an exception.
Considering this sample keyword:
My Keyword
[Arguments] ${condition}
TRY
IF $condition Fail failing text
Do Operation
EXCEPT AS ${exception}
Fail ${exception}
END
If it's called within a normal context (case) and the condition is met, Do Operation will not be executed; but if it's in a teardown, Do Operation is still ran.
This behavior is inline with the expectations set with teardowns - that all calls inside them (and inner for called keywords) are executed, in attempt to clean up the environment.
Still I'd like to nominate the TRY/EXCEPT blocks for different behavior - when there's an exception in a TRY to halt further calls and fall back to the EXCEPT and FINALLY calls. This will allow the usage of exception handling as normal flow control (like in python), and clear workarounds like the one below.
The workaround I'm normally using is to have bogus RETURN statements (or huge embedded IF blocks); for instance in the same example:
My Keyword
[Arguments] ${condition}
IF $condition
Fail failing text
RETURN # just so the next lines are not executed in teardown
END
Do Operation
For a couple of checks that's ok, but when there are more failure conditions (esp later in the flow - like depending on storage data), this gets ugly:
IF $condition
Fail failing text
RETURN # just so the next lines are not executed in teardown
END
${check}= Do Check In SQL
IF not $check
Fail check failed
RETURN # just so the next lines are not executed in teardown
END
# etc
Activity
pekkaklarck commentedon Dec 20, 2023
This is a known problem and reported already in #4293 and #4422. We have decided to not change the default teardown behavior, but instead made it possible to explicitly change it with
robot:recursive-stop-on-failureandrobot:stop-on-failuretags (#4303).Now that I think about this, we possibly could change the behavior so that the default continue-on-failure mode inside the TRY block is stop-on-failure or even recursive-stop-on-failure. This would then be used also in teardowns.
tminakov commentedon Dec 20, 2023
I wasn't aware of the previously logged issues, so apologies for the duplicate.
Obviously the current behavior is raising concerns in the users so changing the default for the TRY would be well accepted.
IMHO the behavior right now is not widely known and thus users to depend on it - e.g. if the default is changed it won't cause too many side effects; and for the ones that do depend on it - there's always the
robot:continue-on-failureandrobot:recursive-continue-on-failuretags to get back to the previous state.pekkaklarck commentedon Dec 20, 2023
I agree we should investigate how hard changing the behavior would be and what kind of effect it would have. It will be at least somewhat backwards incompatible change, so probably best to wait until RF 8.
[-]Exceptions in TRY blocks to halt further executions in teardown[/-][+]Do not continue after failures inside TRY blocks in teardowns[/+]