-
-
Notifications
You must be signed in to change notification settings - Fork 764
Avoid null pointer exceptions when calling getCapabilities #1094
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
return String.format("%s, Capabilities: %s", getClass().getCanonicalName(), | ||
getCapabilities().asMap().toString()); | ||
capabilities != null ? capabilities.asMap().toString() : "null"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd rather use checkNotNull macros everywhere
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
or this is normal that getCapabilities
can sometimes return null?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
getCapabilities
will be null until the response of the new session request, where the real capabilities are returned by the server.
As I mentioned in the description, if the new session command fails (which can be pretty often when you are trying to set up the proper version combination of Appium, Automation and device), this NullPointerException
masks the real failure (with no exception nesting).
So, overall, this makes the initial set up incredibly frustrating.
The idea of this change is to avoid NPEs altogether.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yep, I've checked the Selenium code and it's how it currently works. Although I would like to get the response to SeleniumHQ/selenium#6903 first. What if this is just a bug and not the expected behaviour?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm ok about learning the official posture. However, if RemoteWebDriver
does indeed have a typo (missing a this.
), then the exception masking would still remain. But instead of NullPointerException
, a ClassCastException
would be thrown:
MutableCapabilities capabilities = (MutableCapabilities) super.getCapabilities(); |
In such a case, the fix would be much uglier.
The WebDriver capabilities field remains as null until the new-session command succeeds, returning the capabilities stated by the server. If an exception happens during session creation, some handling code may try to convert the WebDriver instance to string. In which case, the conversion would throw a NullPointerException, masking the real failure. This change just protects against the NullPointerException, so the real session initiation failures can be easily troubleshooted.
Change list
Add null checks to
getCapabilities()
that prevent spurious null pointer exceptions.Types of changes
What types of changes are you proposing/introducing to Java client?
Put an
x
in the boxes that applyDetails
The
capabilities
field inRemoteWebDriver
remains null until a new session is successfully created. If something fails before the Selenium client can consolidate the returned capabilities, aNullPointerException
is thrown from the Appium overridengetCapabilities
methods that masks the real failure.In other words:
getCapabilities
getCapabilities
is calledRemoteWebDriver
returns null, the Appium override tries to call a method on a null valueThis exception masking results in very confusing and misleading troubleshooting.
The fix proposed by this pull request should fix the problem.