Selenium exceptions are extensively used for handling error scenarios and avoiding web application failures. Though there are many Selenium exceptions that may happen in all the Selenium WebDriver code, some Selenium exceptions are specific to the programming languages supported by the framework e.g. Java, C#, Python, etc. This blog covers common Selenium exceptions as well as language specific exceptions, an exhaustive list that can be helpful when you encounter exceptions in your code.
Introduction To Selenium Exceptions
An exception (also referred as fault) is an unprecedented event that occurs during the process of program execution. When an exception occurs, normal program execution halts and the corresponding exception handler is executed. If there is no exception handler to handle that particular exception, the program will return to the calling function that threw the exception eventually leading to termination of the program.
As Selenium test automation is performed on different target platforms, devices, and web browsers; the behavior of the test code can vary depending on the browser type or browser version. For example, some attributes may be browser specific and an exception is thrown if the particular attribute is not present in the browser on which automated browser testing is performed. Common property names can also be browser specific which can lead to Selenium exceptions like NoSuchAttributeException if the same property is not present on the target browser.
Categories Of Selenium Exceptions
There are two broad categories of Selenium exceptions – Checked exceptions and Unchecked exceptions. These exceptions are classified based on the time when the exceptions are caught i.e. compile time or runtime.
A. Checked Exceptions
Checked exceptions in Selenium test automation are handled during the process of test code implementation e.g. NoSuchAttributeException, etc. The handling of checked exceptions occurs during the compile time itself.
If some method is throwing a checked exception, it is better to define a handler that handles that particular exception.
B. Unchecked Exceptions
Unchecked exceptions in Selenium test automation occur during runtime and can have severe repercussions than checked exceptions. e.g. ElementNotVisibleException, MoveTargetOutOfBoundsException, etc.
Exceptions in Java can be checked or unchecked whereas in C++, all exceptions are unchecked. Unchecked exceptions are commonly encountered in automated browser testing related scenarios as the tests span across different combinations and versions of web browsers and operating systems.
Common Selenium Exceptions
1. ElementClickInterceptedException - The Element Click command could not be properly executed as the element that is receiving the Click command was concealed in some way.
2. ElementNotInteractableException - This ElementNotInteractableException’ Selenium exception is thrown when even though the targeted web element exists on the DOM, interactions with that element will hit another web element.
3. ElementNotSelectableException - This Selenium Exception occurs when the target element is present on the DOM but it cannot be interacted with as the element is not selectable. For example, this exception will be thrown when interacting with the script element.
4. ElementNotVisibleException - The most common type of Selenium exception, that is thrown when even though the web element is present but it is not visible. As the element is not visible, any interaction with the element is not possible. This scenario is commonly encountered in Selenium test automation where relevant operation (click, read, etc.) on the web element e.g. button, label, etc. is attempted but the element is hidden from the view. Another example is elements defined in HTML that have type hidden.
5. ErrorInResponseException - This Selenium exception is thrown when some issue or error has occurred on the server side. It could happen when the wrong combination of username & access key is used to access a cloud based remote Selenium Grid, communicating with a remote Web Driver server, or communicating with a Firefox extension (or Chrome add-on).
Some of the common response codes for server-side errors are:
- 401 – Unauthorized
- 400 – BadRequest
- 500 – InternalServerError
- 409 – Conflict
- 403 – Forbidden
- 405 – MethodNotAllowed
6. ImeActivationFailedException - This exception is thrown if the activation of IME (Input Method Engine) has failed for some reason. The ideal manner to handle this is by checking if there is IME support available on the machine.
7. ImeNotAvailableException - This Selenium exception is thrown if IME (Input Method Engine) is not available. ImeNotAvailableException is thrown for every IME-related method in cases where there is IME support that is not available on the test machine.
8. InsecureCertificateException - The usage of expired or invalid TLS certificates caused the user agent to raise a certificate warning.
9. NoSuchFrameException - The NoSuchFrameException Selenium exception is thrown when the frame to be switched-to does not exist.
To avoid such Selenium exceptions, it is recommended to add a sanity check in the automated browser testing code regarding the mode of switching to the frame. Check if the frame index being used is proper. An additional wait of a few milliseconds (ms) can be added to ensure that the loading of the frame is complete.
10. NoSuchWindowException - This exception is thrown when the window target being switched-to does not exist. These scenarios can be taken care of by using window_handles in order to get the current set of active windows. Window handles can be used to perform appropriate actions on the same.