selenide: NoSuchElementException thrown, but ElementNotFound must be catched

The Problem: If it is tried to select a not listed option, then I want to handle the occuring error. The stack trace says the problem is “Caused by: NoSuchElementException”. I know, that I have to catch the “org.openqa.selenium.NoSuchElementException”, but both are not catched, nor even “Exception” is catched. I see that selenide calls throwElementNotFound().

The Workaround: I have to catch “ElementNotFound” to handle this.

The Code:

SelenideElement select = $(By.name("domainsetId"));
        try {
            select.selectOption("ERROR");
        } catch (org.openqa.selenium.NoSuchElementException | NoSuchElementException ex) {
            System.out.println("Not found");
            return false;
        }

The failure trace:

Element not found {by text: ERROR}
Expected: visible
Screenshot: file:/home/XXX/git/selenium/Screenshots/1441620116678.0.png
Timeout: 4 s.
Caused by: NoSuchElementException: no such element
    at com.codeborne.selenide.impl.AbstractSelenideElement.throwElementNotFound(AbstractSelenideElement.java:601)
    at com.codeborne.selenide.impl.WaitingSelenideElement.throwElementNotFound(WaitingSelenideElement.java:75)
    at com.codeborne.selenide.impl.AbstractSelenideElement.waitUntil(AbstractSelenideElement.java:593)
    at com.codeborne.selenide.impl.AbstractSelenideElement.should(AbstractSelenideElement.java:411)
    at com.codeborne.selenide.impl.AbstractSelenideElement.should(AbstractSelenideElement.java:406)
    at com.codeborne.selenide.impl.AbstractSelenideElement.invokeShould(AbstractSelenideElement.java:243)
    at com.codeborne.selenide.impl.AbstractSelenideElement.dispatch(AbstractSelenideElement.java:120)
    at com.codeborne.selenide.impl.AbstractSelenideElement.invoke(AbstractSelenideElement.java:55)
    at com.codeborne.selenide.impl.WaitingSelenideElement.invoke(WaitingSelenideElement.java:19)
    at com.sun.proxy.$Proxy4.shouldBe(Unknown Source)
    at com.codeborne.selenide.impl.AbstractSelenideElement.selectOptionByText(AbstractSelenideElement.java:488)
    at com.codeborne.selenide.impl.AbstractSelenideElement.dispatch(AbstractSelenideElement.java:169)
    at com.codeborne.selenide.impl.AbstractSelenideElement.invoke(AbstractSelenideElement.java:55)
    at com.codeborne.selenide.impl.WaitingSelenideElement.invoke(WaitingSelenideElement.java:19)
    at com.sun.proxy.$Proxy4.selectOption(Unknown Source)
    at com.COMPANY.qm.smgw.MessengerManager.selectMandator(MessengerManager.java:129)
    at com.COMPANY.qm.smgw.msg.MessengerManagerTest.test_selectMandator(MessengerManagerTest.java:81)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
    at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
    at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
    at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
    at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
    at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
    at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
    at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
    at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
    at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
    at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
    at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
    at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
    at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
    at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)

About this issue

Original URL
State: closed
Created 9 years ago
Comments: 41 (19 by maintainers)

Commits related to this issue

#218 add one more test just in case — committed to selenide/selenide by asolntsev 9 years ago

Most upvoted comments

I just came across this thread because - surprise - I just need to catch the exception in selenide. I need to take care of tests I didn’t write… All, watch out as this is going to be strong opinion from my side about what I read here, especially at the beginning.

I must say I am just shocked with your ignorance @asolntsev and your incompetency with regards to automated testing. Few polite people here were explaining the problem about the exceptions and you constantly and stubbornly say “you don’t need it, you don’t need it”. You have no idea about real automation. Of course you think the opposite but the truth is sad. What is more sad you don’t listen to people. Just to give you few facts for you to think of in case you change your mind in the future and start listening to people with more experience on the subject:

tests in the company are not run on local browser as you most probably do - they are run on the selenium grid
tests mostly do not automate web pages but complex application interface
there are many tests which are run at the same time - also on the same machine which hosts selenium
all this makes automated action damn slow, just to give the numbers iterating over 50 rows of the table to assert all the cells in my app lasts few seconds locally but about 40 seconds via the grid
there are additional things like vanishing pop ups, automatically refreshed pages and pages parts etc
thus when there are many tests, if I do not catch exception I will get staleElement or noSuchElementException every run at some place even though all the elements are checked for visibility!
last general note: no, the tests should not be written like you say @asolntsev, but they should be written in domain language either external like Cucumber or internal crafted from e.g. Java to clearly state what they setup, run and assert; selenium/selenide is good for dsl backend only; actually test cases should even not be written but generated from model into executable sets of testcases automatically, but that’s a rocket science isn’t it?

If you don’t change your attitude maybe you should consider creating framework/application for other group - for sure not for QA engineers then.

I must once more emphasize I wrote all this because I am shocked about the way the author of testing framework thinks about automation.

grzegorzgrzegorz on Jun 12, 2019

This is pointless discussion. Finito.

grzegorzgrzegorz on Jul 8, 2019

@asolntsev Yes, there was argumentation from your side that we as selenide users do not need to catch exceptions but it was wrong.

Your first mistake is because you are basing on ElementNotFound exception only while there are other exceptions like the one related to staleness which makes the statement “you do not need to catch exceptions” FALSE. You can design the test to defend from ElementNotFound but you cannot defend from StaleElementReferenceException. No retry will ever help with staleness: $("xxx").click(); will throw StaleElementReferenceException once the page gets refreshed after xxx was found but before it gets clicked. The real smashing feature would be framework which would be smart enough to catch the staleness and repeat the whole command starting with finding xxx again. But this is not the case with selenide.

Your second mistake is you are so identified with your code that you refuse to make simple change so that user can easily find which exception should they catch. Even if this is bad test design (or better say “specific”) users have right to write their tests in their own way. You also do not respect this right.

To sum up: the real trigger of my activity here is your ignorance about the real life testing expressed by your false mantra “you don’t need to catch exceptions”. Either the test design or specific application under test cause the neccesity of catching the exceptions. DOT.

@crocodilechris I must say I am not trying to get any result here. Actually the guy has a right not to change anything and we are free to switch to other framework as you say. I was just pissed off with the “discussion” and my only goal was to kick his ankle so that the guy maybe wakes up. However, I really do not care if he does.

grzegorzgrzegorz on Jun 30, 2019