MINOR: Catch null pointer exception for empty leader URL when assignment is null

[asdf2014]

Catch null pointer exception for empty leader URL when assignment is null.

Committer Checklist (excluded from commit message)

• Verify design and implementation
• Verify test coverage and CI build status
• Verify documentation (including upgrade notes)

[asdf2014]

Hi, @guozhangwang . PTAL.

[guozhangwang]

cc @rhauch @kkonstantine @ewencp

[kkonstantine]

Thanks @asdf2014 for spotting this. I left a comment.

[kkonstantine]

I'd rather not use exception handling for branching. I think I'd prefer to address this case with an earlier check for leaderUrl() == null and instantiate a more informative exception to pass to cb.onCompletion

[asdf2014]

Hi, @kkonstantine @guozhangwang . Already using more informative exception instead of NullPointerException. PTAL.

[rhauch]

One minor suggestion to make it even more readable.

[rhauch]

Maybe leaderUrl.trim().isEmpty() instead?

[asdf2014]

Indeed, isEmpty() is better.

[kkonstantine]

I left a few minor comments to improve the exception message and the readability of the code.

Finally, an observation I have is that we now throw an exception which we know it should (and will) be caught right below. Another way to write this, would be to pass the exception to cb.onCompletion immediately. E.g.

  Exception e = new ConnectException(...);
  cb.onCompletion(e, null);

Since this is not expected to have an impact on the efficiency of the code here, this is more of a stylistic comment than anything else. Up to you @asdf2014

[kkonstantine]

nit: , (comma) doesn't seem required in the sentence.

[asdf2014]

All right. I remove it :-)

[kkonstantine]

suggestion: because the URL of the leader's REST interface is empty
(otherwise it should have been due to the URL of the leader's REST interface being empty)

[asdf2014]

Yep, you are right. It is better.

[kkonstantine]

Although the checkstyle rules currently do not enforce curly brackets in if/else blocks that contain a single statement, because this statement here spans multiple lines, I feel it'd be best to enclose it within { }, even if that's optional.

[asdf2014]

Sure, i will follow the code style.

[asdf2014]

Thanks for your suggestions. Already fixed. @kkonstantine

[asdf2014]

Hi, @rhauch @kkonstantine . This PR has been squashed and rebased. PTAL.

[rhauch]

LGTM. Thanks, @asdf2014!