Open garg3133 opened 7 months ago
I will work on this issue after a week. Looks interesting!
Hey @garg3133 I went through the description I think what you want is a custom error handler to catch these errors and return accordingly as the New Element API isn't returning an apt error message. Please let me know if I am wrong.
@AritraLeo The error "message" is fine here, just the "Error location" section is pointing to the wrong location.
For this, we'd need to see how it happens in the old element API and then implement something similar in the new API.
@AritraLeo The error "message" is fine here, just the "Error location" section is pointing to the wrong location.
For this, we'd need to see how it happens in the old element API and then implement something similar in the new API.
Ohk I get your point so to get the job done exploring how err is thrown in old element api is required.
Description of the bug/issue
The errors coming from the new Element API do not pinpoint the exact location where the command that led to the error was used in the test case.
This is in contrast with the old API which used to show the exact location of command usage in the error stack.
For e.g., if we use
await browser.findElement('.invalid_selector');
, we'd get the following error (the line where thefindElement
command is used is clearly highlighted):On the other hand, when using the new Element API (
await browser.element.find('.invalid_selector');
), we get the following error (the highlight does not show where the command was actually used):Steps to reproduce
Run
await browser.element.find('.invalid_selector');
in any test.Nightwatch.js Version
latest