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