Exceptions in Selenium: Complete List, Causes & How to Handle Them

Huyen Nguyen

Technical Writer, Katalon Updated on

Learn with AI

Selenium exceptions occur when WebDriver encounters an unexpected condition during test execution: an element it can't find, a session that's dropped, or a command that times out. If you're debugging a failing test, identifying the exception type is the fastest path to a fix.

This article covers all 43 exceptions in Selenium: what each one means, the conditions that cause it, and how to handle it. It applies whether you're working in raw Selenium or a framework built on top of it, like Katalon True Platform.

What are Selenium exceptions?

Definition

An exception is known as an unusual or unprecedented event that occurs during the execution of a software program or application. It is a runtime error of an unexpected result or event which influence and disrupt usual program flow. An exception is also considered as a fault.

Classification of Selenium exceptions

Selenium exceptions are divided into two types including Checked Exceptions and Unchecked Exceptions.

1. Checked Exceptions

Checked Exceptions are handled during the process of writing codes. These exceptions are handled before compiling the code, therefore, such exceptions are examined at the compile time.

2. Unchecked Exceptions

These exceptions are thrown at runtime. Unchecked exceptions are more catastrophic than the compile-time exception as it causes problems while running Automation pack in headless.

The complete list of exceptions in Selenium

1. ConnectionClosedException: This exception takes place when there is a disconnection in the driver.

2. ElementClickInterceptedException: The command could not be completed as the element receiving the events is concealing the element which was requested clicked.

3. ElementNotInteractableException: This Selenium exception is thrown when an element is presented in the DOM but it is impossible to interact with such element.

4. ElementNotSelectableException: This Selenium exception is thrown when an element is presented in the DOM but is unavailable for selection. Hence, it is impossible to interact with.

5. ElementNotVisibleException: This type of Selenium exception takes place when an existing element in DOM has a feature set as hidden. In this situation, elements are there, but you can not see and interact with the WebDriver.

6. ErrorHandler.UnknownServerException: Exception is used as a placeholder if the server returns an error without a stack trace.

7. ErrorInResponseException: This exception is thrown when a fault has occurred on the server-side. You can see it happens when interacting with the Firefox extension or the remote driver server.

8. ImeActivationFailedException: This exception occurs when IME engine activation has failed.

9. ImeNotAvailableException: This exception takes place when IME support is unavailable.

10. InsecureCertificateException: Navigation made the user agent to hit a certificate warning, which is caused by an invalid or expired TLS certificate.

11. InvalidArgumentException: This Selenium exception is thrown if an argument does not belong to the expected type.

12. InvalidCookieDomainException: This happens when you try to add a cookie under a different domain rather than the current URL.

13. InvalidCoordinatesException: This happens if the coordinates offered to an interacting operation are not valid.

14. InvalidElementStateException: This Selenium exception occurs if a command cannot be finished as the element is invalid.

15. InvalidSessionIdException: Takes place when the given session ID is not included in the list of active sessions, which means the session does not exist or is inactive either.

16. InvalidSwitchToTargetException: Happens if the frame or window target to be switched does not exist.

17. JavascriptException: This problem happens when executing JavaScript supplied by the user.

18. JsonException: Happens when you afford to get the session capabilities where the session is not created.

19. MoveTargetOutOfBoundsException: Takes place if the target provided to the ActionChains move() methodology is not valid. For example: out of the document.

20. NoAlertPresentException: Happens when you switch to no presented alert.

21. NoSuchAttributeException: Occurs when the attribute of the element could not be found.

22. NoSuchContextException: Happens in mobile device testing and is thrown by ContextAware.

23. NoSuchCookieException: This exception is thrown if there is no cookie matching with the given path name found amongst the associated cookies of the current browsing context’s active document.

24. NoSuchElementException: Happens if an element could not be found.

The most common cause of NoSuchElementException is a broken locator: the XPath or CSS selector your test uses to find an element no longer matches anything in the DOM. This usually happens because the UI changed, the element is inside an iframe, or the locator was too brittle to begin with. Before debugging the exception itself, it's worth reviewing how to write stable XPath and CSS selectors - a more resilient locator will often prevent the exception from occurring at all.

25. NoSuchFrameException: Takes place if frame target to be switch does not exist.

26. NoSuchWindowException: Occurs if window target to be switched does not exist.

27. NotFoundException: This exception is a subclass of WebDriverException. It happens when an element on the DOM does not exist.

28. RemoteDriverServerException: This Selenium exception is thrown when the server does not respond due to the problem that the capabilities described are not proper.

29. ScreenshotException: It is impossible to capture a screen.

30. ScriptTimeoutException: Thrown when executeAsyncScript takes more time than the given time limit to return the value.

31. SessionNotCreatedException: A new session could not be successfully created.

32. SessionNotFoundException: The WebDriver is performing the action right after you quit the browser.

33. StaleElementReferenceException: This Selenium exception happens if the web element is detached from the current DOM.

StaleElementReferenceException is thrown when the element your test previously located no longer exists in the DOM, typically because a page reload or dynamic update detached it. Revisiting your XPath and CSS selector strategy can help here: using contains() or attribute-based selectors that target the stable part of an element's identity makes it easier to re-locate after DOM changes.

34. TimeoutException: Thrown when there is not enough time for a command to be completed.

35. UnableToCreateProfileException: You can open a browser with certain options using profiles, but sometimes a new version of the Selenium driver server or browser may not support the profiles.

36. UnableToSetCookieException: Occurs if a driver is unable to set a cookie.

37. UnexpectedAlertPresentException: This Selenium exception happens when there is the appearance of an unexpected alert.

38. UnexpectedTagNameException: Happens if a support class did not get a web element as expected.

39. UnhandledAlertException: It happens when there is an alert, but WebDriver is unable to perform Alert operation.

40. UnknownMethodException: Thrown when the requested command matches with a known URL but not matching with a methodology for that URL.

41. UnreachableBrowserException: This Selenium exception happens if the browser is unable to be opened or has crashed because of some reasons.

42. UnsupportedCommandException: Occurs when remote WebDriver does not send valid commands as expected.

43. WebDriverException: This takes place when the WebDriver is performing the action right after you close the browser.sol

Selenium exceptions handling

What is Exception handling?

In a software program, an atypical event (e.g. unrecognized messages) can interfere with the regular execution flow. These events, if not handled properly, can result in termination of the program by immediate throwing exceptions. Handling exceptions is the process of managing these atypical events in order to prevent such problems from arising.

Exception handling in Selenium: methods and examples

In order to handle these above types of Selenium exceptions, this article will discuss some compiler directives to support exception handling.

Throw: Throw keyword is used to throw exception to the runtime to handle it.

Copy

// Method Signature\

public static void anyFunction ( ) throws Exception {

try {

// write your code here

} catch ( Exception e ) {

// Do whatever you wish to do here

// Now throw the exception back to the system

throw ( e ) ;

}

}

Multiple Catch blocks: You can have multiple @catch() blocks to catch different types of exception. The syntax for multiple catch blocks looks like the following:

Copy

try
 
{
 
   //Some code
 
} catch ( ExceptionType1 e1 ) {
 
   //Code for Handling the Exception 1
 
} catch ( ExceptionType2 e2 ) {
 
   //Code for Handling the Exception 2
 
}

Try/Catch: A @try block encloses code that can potentially throw an exception. A @catch() block contains exception-handling logic for exceptions thrown in a @try block. Code within a try/catch block is referred to as protected code, and the syntax for using try/catch looks like the following:

Copy

try
 
{
 
// Some code
 
} catch ( Exception e ) {
 
// Code for Handling the exception
 
}

Finally: A @finally block contains code that must be executed whether an exception is thrown or not:

Copy

try
 
{
 
   //Protected code
 
} catch ( ExceptionType1 e1 )
 
{
 
   //Catch block
 
} catch ( ExceptionType2 e2 )
 
{
 
   //Catch block
 
} catch ( ExceptionType3 e3 )
 
{
 
   //Catch block
 
} finally
 
{
 
   //The finally block always executes.
 
}

Selenium exception examples

Example 1: TimeoutException using Selenium WebDriver.

Copy

import static com . kms . katalon . core . testobject . ObjectRepository . findTestObject
import org . openqa . selenium . TimeoutException
import com . kms . katalon . core . logging . KeywordLogger
import com . kms . katalon . core . util . KeywordUtil
import com . kms . katalon . core . webui . keyword . WebUiBuiltInKeywords as WebUI
 
 
try {
WebUI . click ( findTestObject ( "Page_Register/btn_register" ) )
 
} catch ( TimeoutException toe ) {
WebUI . waitForElementClickable ( findTestObject ( "Page_Register/btn_register" ) , 20 )
WebUI . click ( findTestObject ( "Page_Register/btn_register" ) )
 
} catch ( Exception e ) {
KeywordUtil . markError ( "Register button is not found." )
 
throw ( e ) ;
 
}

Example 2: Let’s assume that in Selenium WebDriver you want to verify the presence of any element on the page. You would not be able to get this with an element locator. If the element is present, your locator will work and you will easily be able to print that the element is present. However, in this case, your element is not present on the page, your locator fails and simply throws the exception. Therefore, this case would be easily solved by using the self-written function.

Copy

import static com . kms . katalon . core . testobject . ObjectRepository . findTestObject
import org . openqa . selenium . WebDriver
import com . kms . katalon . core . webui . common . WebUiCommonHelper
 
boolean verifyObjectPresent ( ) { 
try {
WebUiCommonHelper . findWebElement ( findTestObject ( "Page_Report/lblReport" ) , 20 ) 
return true ;
 
} catch ( Exception e ) {
 
return false ;
 
} 
}

Conclusion

We have listed all 43 types of exceptions in Selenium along with the conditions that trigger them. Understanding these exceptions is only half the battle, the other half is building tests that are resilient enough to avoid them in the first place.

That means writing stable locators (see our guide on XPath and CSS selectors), applying proper wait strategies, and structuring your test architecture so failures surface quickly and clearly.

Katalon True Platform is built to reduce the friction that leads to these exceptions. The platform's Katalon AI Assistant, including the Root Cause Analyzer and Bug Reporter, help teams identify why a test failed and trace it back to the right code change, without manual log digging. The Test Runner and Test Case Generator work from your requirements directly, while Kai, the platform-wide AI assistant, helps you build and refine test objects so your locators stay current as the UI evolves.

Whether you're handling exceptions in a raw Selenium setup or scaling test automation across web, mobile, and API, Katalon True Platform gives your team the infrastructure to move faster with fewer surprises.

Explain

FAQs on Selenium Exceptions

What is an exception in Selenium?

A Selenium exception is a runtime error thrown by WebDriver when it encounters a condition it cannot handle, such as an element it can't find, a session that has dropped, or a command that exceeds its timeout. Exceptions stop test execution at the point of failure unless they are caught and handled.

Unlike bugs in application code, Selenium exceptions are predictable: each one has a defined cause, which means identifying the exception type is usually the fastest path to a fix.

What is the difference between checked and unchecked exceptions in Selenium?

Checked exceptions are handled at compile time, the code must explicitly address them before it can be compiled, so they are caught during the writing phase. Unchecked exceptions are thrown at runtime and are not enforced by the compiler. In practice, most Selenium exceptions are unchecked: they surface only when the test actually runs, often in headless or parallel environments where conditions differ from local execution. NoSuchElementException, StaleElementReferenceException, and TimeoutException are all unchecked exceptions. They will not be flagged by your IDE but will terminate a test run if unhandled.

What is the most common exception in Selenium?

NoSuchElementException is the most frequently encountered Selenium exception. It is thrown whenever WebDriver cannot find an element matching the given locator in the DOM at the time the command runs. The root cause is almost always one of three things: a locator that has broken because the UI changed, an element that lives inside an iframe the test has not switched into, or a timing issue where the test acts before the element has loaded. The fix starts with the locator. See the section on writing stable XPath and CSS selectors before adding wait logic.

What is the difference between NoSuchElementException and StaleElementReferenceException?

NoSuchElementException means WebDriver looked for an element and found nothing — the locator matched zero elements in the current DOM. StaleElementReferenceException means WebDriver previously found and stored a reference to the element, but by the time it tried to interact with it, that element had been removed or replaced in the DOM (typically because of a page reload or a dynamic UI update).

In short: NoSuchElementException is a lookup failure; StaleElementReferenceException is a stale reference failure. The fix for both involves re-evaluating your locator strategy — a more resilient locator using contains() or stable attributes reduces the chance of both exceptions occurring.

How do you handle exceptions in Selenium?

The four standard approaches to exception handling in Selenium are:

Try/Catch — wrap the code that might fail in a try block and define handling logic in the paired catch block. This is the most common pattern and keeps the test running past a handled failure.
Multiple Catch blocks — use separate catch blocks for different exception types from the same try block, so each exception class gets its own handling logic.
Throw — use the throw keyword to explicitly escalate an exception to the calling method rather than handling it locally. Useful in helper functions where the caller should decide how to respond.
Finally — a finally block runs regardless of whether an exception was thrown. Use it for cleanup actions like closing the browser driver or releasing resources.

Can Katalon True Platform help reduce Selenium exceptions?

Yes. Most Selenium exceptions stem from three sources: brittle locators, timing issues, and test failures that are hard to trace back to a root cause. Katalon True Platform addresses all three. The platform's Katalon AI assistant helps build and maintain stable test objects so locators stay current as the UI evolves. The Root Cause Analyzer agent pinpoints why a test failed without manual log digging, and the Bug Reporter automatically generates structured failure reports. For teams scaling beyond raw Selenium, this reduces the time spent debugging exceptions and increases the signal-to-noise ratio of your test results.

Huyen Nguyen

Technical Writer, Katalon

Huyen Nguyen is an experienced technical writer in the software testing industry. With strong technical expertise and a deep understanding of Katalon products, she creates clear, practical guides that support testers at every skill level.