In Selenium 4, how do the error, message and stacktrace members of a failed command help you locate the fault?
answer
- Three members describe the failure
- One of them is a fixed code
- That code chooses the exception class
- The trace belongs to the driver
- Message names the concrete specifics
basics
~10 sThe error member is a fixed code the client maps onto an exception type, the message is the driver's text naming the specifics, and the stacktrace comes from the remote end, not your test.
solid answer
~50 sA failed Selenium 4 command still returns the normal envelope, but `value` holds an error object. `error` is a fixed specification code such as `no such element`, `invalid session id` or `session not created`, and the client binding maps it onto the exception class you catch - so it drives control flow and is stable across drivers and languages. `message` is free-form driver text carrying the specifics worth quoting into a failure report, but it is unstable enough that asserting on its wording is a trap. `stacktrace` is the remote end's own trace, not your test's, so it confirms which side refused the command rather than pointing at your code. In triage: a well-formed error object proves the command reached a remote end at all, the code tells you which family of failure it is, and the message usually names the concrete cause.
code
java · 14 linesimport org.openqa.selenium.By;
import org.openqa.selenium.NoSuchElementException;
import org.openqa.selenium.WebDriver;
public final class OverdueVehicleLookup {
public static String workOrderId(WebDriver driver) {
try {
return driver.findElement(By.id("work-order-id")).getText();
} catch (NoSuchElementException e) {
throw new AssertionError("remote end reported: " + e.getMessage(), e);
}
}
}go deeper
Know that a failed command comes back with an error code plus a message from the driver, and that your client turns it into the exception you catch. Read the message before changing anything.
Explain the mapping: a fixed code string chooses the exception class, and the message is human text. Be able to name a few codes and say which member is stable and which is not.
Show a triage order. Prove the command reached a remote end, read the code to pick the family of failure, quote the message into the report, and use the trace only to confirm which side refused you.
Own the reporting standard. Decide that every failure record captures all three members automatically, so a pipeline failure can be diagnosed without a reproduction run and without anyone re-running the suite by hand.
## The three members of a failed command When a command against a Selenium 4 remote end fails, the response still arrives in the ordinary envelope, but the `value` member holds an **error object** rather than a result. That object has three members you will use constantly and one you will rarely see: - **`error`** — a fixed code string defined by the specification, such as `no such element`, `stale element reference`, `invalid session id`, `session not created`, `javascript error` or `no such window`. It is machine vocabulary: a closed set, identical across every driver and every client language. - **`message`** — free-form human text written by the driver that produced it. This is where the useful specifics live: the selector that matched nothing, the element that swallowed a click, the version mismatch that refused a session. - **`stacktrace`** — a trace from the **remote end**, not from your test. - **`data`** — optional, present only for the few errors that carry structured extra detail. ## Which member is load-bearing, and which is only readable The distinction that separates a senior answer from a junior one is knowing what each member is *for*: 1. **`error` drives control flow.** The client binding maps the code string to an exception class, which is precisely how a missing row on the fleet scheduler's overdue-vehicle list arrives in your test as a `NoSuchElementException` rather than as a parsing problem. Two drivers phrase their messages differently; they must not phrase the code differently. 2. **`message` drives diagnosis.** It is the first thing to print into a failure report, because it usually names the concrete thing that went wrong on this run. It is also unstable text: asserting on its wording is a trap, since a driver upgrade may reword it freely. 3. **`stacktrace` answers a different question entirely** — see below. ## Whose stack is the stacktrace It is the remote end's stack, captured inside the driver, and this is where candidates most often go wrong. It does not contain your test method, your page object, or the line of Java that called `click()`. It contains driver-internal frames. That makes it a signal about *which side* failed rather than a pointer to the offending test code: | What you see | What it tells you | |---|---| | A recognised `error` code plus a specific `message` | The remote end understood the command and refused it for a stated reason - a genuine application or timing fault | | An unexpected code such as `unknown command` | The route you sent does not exist on that remote end - a client or version mismatch, not an application fault | | `invalid session id` | The remote end no longer holds a session under the id in your path: the browser or driver is gone, or the session was already deleted | | No response at all, or a transport failure | The request never got an answer; the fault is on the path, not in the browser | ## Walking the path when the fleet suite fails in the pipeline The scheduler's suite passes locally and fails in the pipeline against a remote end on another host. The triage order that actually works: 1. **Did the command reach a remote end?** A well-formed error object means it did, and you can stop suspecting the network. No answer at all means the fault is between the local end and whatever should have replied. 2. **Read `error` before `message`.** The code tells you which family of failure this is; a `session not created` on the very first command is a completely different investigation from a `no such element` on the fifth screen. 3. **Read `message` for the specifics**, and quote it verbatim into the failure record. It usually contains the one detail nobody can reconstruct after the run has ended. 4. **Use `stacktrace` to confirm the side**, not the cause. If the trace is driver-internal and the message is specific, the browser stack behaved correctly and refused you for a real reason. ## What to do with each outcome - A specific code with a specific message is a **real finding**: the page did not present what the case expected, and the case, the fixture data or the application is at fault. - A `session not created` or an `invalid session id` early in a run is **environment**: the remote end could not start or keep a browser, and no amount of test-side change will fix it. - A code your client does not recognise, or an `unknown command`, points at a **mismatch between the client and the remote end**, not at the page under test. - A missing response is a **path problem**, and the useful evidence lives in the driver's own log rather than in the test output. The habit worth demonstrating is capturing all three members into the failure record automatically. A report that says only `NoSuchElementException` has thrown away the `message` the remote end took the trouble to write, and that message is usually the whole answer.
- Why should a suite never assert on the text of the message member?Because it is free-form text owned by the driver, not by the specification. Two drivers word the same failure differently, and an upgrade can reword it without breaking anything. Assert on the `error` code, or on the exception type the client derived from it, and keep the message for the human reading the report.
- Your run fails with an invalid session id on the third command. Where do you look first?At the remote end, not the test. That code means the driver no longer holds a session under the id in the request path - the browser crashed, the driver restarted, or something already deleted the session. The driver's own log for that session id carries the reason; the test code is almost never the cause.
- What is the difference between getting a well-formed error object and getting no response at all?An error object proves the request reached something that speaks the protocol and that it deliberately refused the command. No response means the request died on the path - the remote end was unreachable, the process went away, or an intermediary dropped it - and the evidence lives in process and connection logs rather than in the browser.
saying these in an interview costs you the question
- Thinks the stacktrace member shows the test's own call stack
- Asserts on the wording of the message member in tests
- Treats invalid session id as a bad selector problem
- Logs only the exception type and discards the driver's message
- Believes error codes differ between drivers and client languages