You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
call initErrorHandler(control="YES", errAction="RETURN", traceback="YES")
<do something that should not throw an error>
if (getLatestError() /= 0) then
call test%set_any_error(<test name>)
end if
call resetError()
For such kind of setup, the body of the set_any_error() routine is not executed as the check-in procedure through the ENTER_NORMAL_PROCEDURE() macro directly returns, as an error occurred previously.
The direct workaround for the above case then is:
call initErrorHandler(control="YES", errAction="RETURN", traceback="YES")
<do something that should not throw an error>
if (getLatestError() /= 0) then
call resetError()
call test%set_any_error(<test name>)
end if
Accordingly, the error has to be reset before calling the set_any_error() routine in order to actually access its main body.
Nevertheless, this hot-fix is not intuitive and easy to oversee for someone, who is not familiar with this behavior. If this sequence (first reset then throw error) is missed, an actual error may remain unrecognised during testing.
There seem to be three possible options to fix this problem:
Not to check-in the set_any_error() routine by deleting the entry and exit macros. This is problematic, as the routine itself can throw an error, if the total number of errors surpasses a specific threshold.
Add a forced entry macro, which does not check whether an error occurred previously. Here, the potential side effects of such forced check-in are unclear.
Replace the call t%log_fatal("Too many errors in test: "//this%test_name) by a simple fatal error, which is not thrown through the slam_tehl_class.
The text was updated successfully, but these errors were encountered:
There are test cases of the following form:
For such kind of setup, the body of the
set_any_error()
routine is not executed as the check-in procedure through theENTER_NORMAL_PROCEDURE()
macro directly returns, as an error occurred previously.The direct workaround for the above case then is:
Accordingly, the error has to be reset before calling the
set_any_error()
routine in order to actually access its main body.Nevertheless, this hot-fix is not intuitive and easy to oversee for someone, who is not familiar with this behavior. If this sequence (first reset then throw error) is missed, an actual error may remain unrecognised during testing.
There seem to be three possible options to fix this problem:
set_any_error()
routine by deleting the entry and exit macros. This is problematic, as the routine itself can throw an error, if the total number of errors surpasses a specific threshold.call t%log_fatal("Too many errors in test: "//this%test_name)
by a simple fatal error, which is not thrown through theslam_tehl_class
.The text was updated successfully, but these errors were encountered: