Open Nepitwin opened 2 years ago
Why do you have the need to enable or to disable Exception handeling by flauilibrary you can raise your error as usual. It does not make sense to not to capture the raised errors from flaui but only forwarding them to robot user.
In other hand this upgrade from robot is an only visual improvement of an already existing functionality given by Run Keword And Except Error keyword.
TRY EXCEPT Cases are by Robotframework 5 included and contains a better error use case handling than Run Keyword And Except Error because you can handle different type of errors on mutliple ways and the readability is better than the current keyword usage this is why RF 5 implemented then for a better clean code aspect and error improvment by test cases.
Robotframework-Flaui already supports this behavior because you can catch all FlaUI Exception and make your own error handling decision for all tests. This must be documentated only to see which type of errors you can handle.
TRY
test.Timeout
EXCEPT FunctionTimedOut
Log 1
EXCEPT FAIL INSIDE
Log 2
EXCEPT FunctionTimedOut: Function timeout
Log 3
END
I have wrote a test function which is below in a class.
@func_set_timeout(2)
def timeout(self):
time.sleep(3)
print('impossible')
However, when I run Robotframework, the error named FunctionTimeout is not captured by TRY/EXCEPT
The error shows
[FAIL (+2.07s)] FunctionTimedOut: Function timeout (args=(<test.test object at 0x00000227AA09E2B0>,)) (kwargs={}) timed out after 2.000000 seconds.
@ArmenNoir Sorry for very late replay because your comment was not related to this issue we have discussed here. The function timeout in your test class is not failing, so you can catch nothing in robot test case, if nothing is failing
@Nepitwin As i mentioned: There is no need for any internal change or to implement a new keyword to enable or disable exception handling. We raise our failure message if the keyword fails. One keyword may have more than one possible error message, which is already the case for some keywords, and this can now be catched easily under robot because of new syntax. So my suggestion is to close this issue.
Robotframework 5 (https://github.com/robotframework/robotframework/releases/tag/v5.0a1) contains now a try except block. Currently all keywords are implemented to handle error messages internally by robotframework-flaui By these code changes all keywords can be used by an internal try except block and handle errors individually.
Full release notes https://github.com/robotframework/robotframework/blob/master/doc/releasenotes/rf-5.0a1.rst
Sample code by robotframework 5
For this case it would be nice to extend robotframework-flaui by these type of code handling. For fallback usage developer should be decide if error handling should be used as old message style or as except.
By these two type of keywords user can decide the new approach or to use old robotframework 4 usage