Don't use VerifyElementPresent keyword to test if–else or looping logic

Tips and Tricks
1

Information for new Katalon users, experienced users might surely be knowing, the below topic.
**
verifyElementPresent is NOT suitable for normal if–else or looping logic unless you explicitly change its FailureHandling.** By default, it behaves like an assert, not a boolean checker.

:white_check_mark: Why this happens (root cause)

:one: verifyElementPresent is an assert-style keyword

Although the documentation says it returns a boolean, in practice:

  • :white_check_mark: If the element is present → returns true

  • :cross_mark: If the element is NOT present → throws StepFailedException

  • The exception happens before your else block, so your script breaks

This is confirmed both by Katalon Docs and by multiple community reports over the years. [WebUI] Verify Element Present | Katalon Docs ,

This is why this logic works only when the element exists, but crashes when it doesn’t.

:white_check_mark: Example of the problematic pattern (what you tried)

if (WebUI.verifyElementPresent(obj, 5)) {

// create booking

} else {

// alternate

:red_circle: When element is not present, Katalon throws:

StepFailedException: Unable to verify object is present

Your else is never reached.

:white_check_mark: Correct ways to implement if–else / loop logic

:white_check_mark: Option 1 (BEST PRACTICE) – Use waitForElementPresent

This keyword is designed for conditional logic.

if (WebUI.waitForElementPresent(obj, 5)) {

// element exists → create booking

} else {

// element does not exist → alternate flow

}

:check_mark: Returns true / false
:check_mark: No exception
:check_mark: Safe inside loops

This is the official recommendation from Katalon engineers. [WebUI] Wait For Element Present | Katalon Docs , Understand waiting keywords in Katalon Studio | Katalon Docs

:white_check_mark: Option 2 – Use verifyElementPresent with FailureHandling

If you really want to use verifyElementPresent, you must override FailureHandling:

if (WebUI.verifyElementPresent(obj, 5, FailureHandling.CONTINUE_ON_FAILURE)) {

// present

} else {

// not present

}

This prevents the exception and allows false to be returned. verifyElementPresent & verifyElementNotPresent method

:warning: Still not recommended inside loops (logs failures repeatedly).

:white_check_mark: Option 3 – Try–catch (advanced / not preferred)

try {

WebUI.verifyElementPresent(obj, 5)

// present

} catch (Exception e) {

// not present

}

``

Works, but:

  • :cross_mark: Noisy logs

  • :cross_mark: Not clean

  • :cross_mark: Poor readability

:white_check_mark: What Katalon engineers & community say (important)

From Katalon Community:

“Verify keywords behave like assertions.”
Use waitFor* keywords when you want boolean checks.

This behavior has existed since 2018+ and is not considered a bug anymore, just a design choice.

:white_check_mark: Recommended decision table

Use case Keyword
Assertion (test must fail) verifyElementPresent
If–else logic waitForElementPresent :white_check_mark:
Looping checks waitForElementPresent :white_check_mark:
Optional UI flow waitForElementPresent :white_check_mark:

:white_check_mark: Final Conclusion

:cross_mark: verifyElementPresent is not reliable for loop or conditional checks by default
:white_check_mark: This behavior is documented, discussed, and acknowledged
:white_check_mark: **Use waitForElementPresent for your scenario (booking creation logic)

**

This issue does not occur in frameworks that treat element checks as pure boolean logic rather than implicit assertions. If Katalon shifts from its current verification‑as‑assertion model to this programmatic approach—where checks simply return true or false and assertions are explicitly defined—if–else conditions and loops would behave predictably without unexpected failures.

4 Likes