Skip to content
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

Avoid null pointer exceptions when calling getCapabilities #1094

Merged
merged 1 commit into from
Feb 5, 2019
Merged

Avoid null pointer exceptions when calling getCapabilities #1094

merged 1 commit into from
Feb 5, 2019

Conversation

etanol
Copy link
Contributor

@etanol etanol commented Jan 29, 2019

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 apply

  • No changes in production code.
  • Bugfix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)

Details

The capabilities field in RemoteWebDriver remains null until a new session is successfully created. If something fails before the Selenium client can consolidate the returned capabilities, a NullPointerException is thrown from the Appium overriden getCapabilities methods that masks the real failure.

In other words:

This exception masking results in very confusing and misleading troubleshooting.

The fix proposed by this pull request should fix the problem.

@jsf-clabot
Copy link

jsf-clabot commented Jan 29, 2019

CLA assistant check
All committers have signed the CLA.

return String.format("%s, Capabilities: %s", getClass().getCanonicalName(),
getCapabilities().asMap().toString());
capabilities != null ? capabilities.asMap().toString() : "null");
Copy link
Contributor

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

Copy link
Contributor

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?

Copy link
Contributor Author

@etanol etanol Jan 31, 2019

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.

Copy link
Contributor

@mykola-mokhnach mykola-mokhnach Jan 31, 2019

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?

Copy link
Contributor Author

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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants