Unhandled exception type Interrupted Exception



Hi all
I have a helpermethods.java file in the UItest folder. It is very simple and has worked in other solutions but for some reason, when I try to call a method in this class, I get an error that I need to surround it with a try catch. I have never had this error in my other solution so I am not sure what is going on.
I import it:
import uitest.HelperMethods;
I instantiate it:
HelperMethods helper = new HelperMethods(driver);

and then in the code I try the following:
and I get a red line saying that I have an unhandled exception.
Here is the contents of HelperMethods.java

package uitest;

import uitest.TestNgTestBase;
import uitest.pageobjects.*;

import java.util.ArrayList;
import java.util.List;
import java.util.Set;
import java.util.concurrent.TimeUnit;

import org.openqa.selenium.By;
import org.openqa.selenium.Keys;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.interactions.Actions;
import org.testng.Assert;
import org.testng.annotations.Test;

public final class HelperMethods {

    private WebDriver driver;    
    public HelperMethods (WebDriver driver) {
        this.driver = driver; 

    public void Maximize() {
    public void Wait() {
        driver.manage().timeouts().implicitlyWait(5, TimeUnit.SECONDS);


Hey there @micheleaz,

this is because you’ve mistakenly picked wait, which comes from java.lang.Object and is throwing a InterruptedException, instead of your custom method Wait. Note the difference in the capital W starting letter.

Now aside of that issue I wanted to note that using implicitWaits is kind of a bad practice. There are two good answers on SO about that.
In general it makes it harder for you to spot issues and could lead to undesired behavior of your tests.

Instead Ranorex Webtestit enforces best practices with explicit waits, where you can control when and for how long the driver should wait for the element. If you take a look at our click snippet you’ll see the following (I’ll make comments in the code):

public class MyPo {
    private By myElement = By.cssSelector("#myelementid");

    protected WebDriver driver;
     * We define a class wide WebDriverWait control handler.
    *  This guarantees that every wait will exactly wait with the exact same behavior
    protected WebDriverWait wait;

    public MyPo(WebDriver driver) {
        this.driver = driver;
         * By default the wait will be defined with a 10secs timeout.
         * You're free to change this according to your preference
        this.wait = new WebDriverWait(driver, 10);

    public MyPo clickMyElement() {
         * Every snippet in Ranorex Webtestit will make sure to always properly
         * wait for any elements visibility before trying to perform actions on it.
         * This is to make sure the test behaves the same way as the user
         * would interact with your site. ( Can't see, can't click ;) )
        return this;


Thanks for your feedback. There is one problem. The wait for the element to appear is great in theory and should work in theory, but in practice, it doesn’t work. Our web apps do many calculations and such on the fly and sometimes takes a bit for it to popup. I consistently get errors that could not find element or expected blah and could not find it so boolean check is false, not true. In practice, if I put in explicit waits, I no longer get these errors and the test passes. I consistently in fact put in explicit waits before my boolean checks and have been pretty stable. I understand what you say completely, but in practice the wait until element appears doesn’t work, at least for us.


Also thanks for you catching the wait versus Wait… I couldn’t see the problem.
Thanks again!


Yeah that one was super easy to overlook. Just in case you didn’t see the feature, the Editor will add squiggly lines below the part of code which is wrong. Once you hover these, you’ll get a box popping up explaining the issue. This is how I noticed the type of Exception returned and the full methods serialization (java.lang.Object.wait).

As for the explicit wait issues. We’d really be interested to understand what the cause for your troubles was. Keep in mind that the default ExpectedCondition is visibilityOfElementLocated, which may or may not suite every rare situation. In general if a user can see something, he can interact with it, which is why this is the default.
Could you perhaps replicate a typical issue you have on a public accessible site? This way we can look into it and perhaps figure out what went south.

Using implicit waits is not going to make the world stop turning, nope for sure :wink: Yet it really should be somewhat the last resort, so I hope we can figure out together where the original issue resides.


Hi @vsoftic. I will try to find a publicly accessible site that does some calculations or some such process intensive calculations in the background and see if I can get it to happen. I will let you know.