Robotframework: Native support for `TRY/EXCEPT` functionality

[pekkaklarck]

The plan is to add support for native IF/ELSE syntax in RF 3.3. See the discussion in #3074 for background information why we think adding this kind of programmatic features is a good idea. Another similar and commonly needed feature is TRY/EXCEPT functionality to ease handling errors. Currently it is possible to use Run Keyword And Expect Error and Run Keyword And Ignore error but they are awkward similarly as Run Keyword If is an awkward replacement for IF/ELSE syntax.

Exact semantics how TRY/EXCEPT will work are not yet clear. They will be decided later before implementation starts. A precondition is a new parser, similarly as for IF/ELSE, and we also consider IF/ELSE more important and will start implementing it first.

[Snooz82]

Just an idea:

At the moment we have already TRY/FINALLY with teststeps and Teardown.
Teardown can be on every level.

What is missing is only a [On-Error] setting.
If we would have this [On-Error] we could also do stuff like capture screenshots there and closing connections an so on.

I personally would not like to see a real TRY/EXCEPT like IF/ELSE, because the we start re-implementing Python.
[On-Error] is also understandable for non programmers.

*** Test Cases ***
Test
    [Setup]     Open Browser.   http://example.com
    Do Keyword
    Some Other Test
    [On-Error]    Save error log and capture Screenshot
    [Teardown]    Close All Browsers

Same could work on Suite and on Keyword Level.

*** Settings *** 
Suite Setup   Open Browser
Error Handler    Save error log and capture Screenshot
Suite Teardown    Close All Browsers

[pekkaklarck]

I've been thinking about adding an on-error handler but nowadays I think TRY/EXCEPT would probably be better. Some of the problems I see with on-error handler:

• Unless on-error can also ignore the error, it's not really different from teardown with Run Keyword If Test Failed.
• If on-error should be able to ignore errors, it needed to get exception information as argument to be able to do decisions based on that.
• One test (or keyword) could only have one on-error handler. If there were multiple possible errors to handle, the handler would get complicated.

I got a feeling TRY/EXCEPT would be a lot more generic solution. In simple cases on-error might be easier to understand, but in more complex scenarios TRY/EXCEPT would be a lot more flexible.

I also don't see problems in Robot's syntax moving towards a general very high level programming language. After replacing Run Keyword If with IF/ELSE and Run Keyword And Expect/Ignore Error with TRY/EXCEPT, we can look at replacing Exit/Continue For Loop with BREAK/CONTINUE, [Return] and Return From Keyword with RETURN, and so on.

[mkorpela]

How does this relate to expecting an error to happen? In otherwords many cases in tests the situation is so that an error must happen as expected, test should fail if not.

[pekkaklarck]

We could support TRY/EXPECT/ELSE like Python to support that use case.

[mkorpela]

One of the strongest selling points of Robot Framework is the simplicity for people coming from a non-IT-background. I think we should consider how easy a new core concept is to learn and how easy it is to teach.
TRY/EXCEPT goes some steps towards more complex concepts.

[Snooz82]

I do see usecases for Try/Except but these are mostly better done in python.

I always hate it when i see testspecs with try catch in it. People try to implement execution logic into test design.

@pekkaklarck you mentioned the "Run Keyword If Test Failed" this imho does not work on keyword level. But there are imho regular cases where you want to clean up or do stuff if something fails. And using TRY EXCEPT for this would imho be too technical. 🤷🏻‍♂️