Just hit a NullPointerException in some code:
public boolean isOwner()
{
return authManager.getUser().equals(blog.getOwner());
}
Turns out, sometimes getUser() returns null. I started to retype this, then thought: "Can IntelliJ help me?"
Answer: yes. Because of IntelliJ coolness, I click anywhere in the expression, type option-enter and choose 'Flip .equals()' and it rewrites the code to:
public boolean isOwner()
{
return blog.getOwner().equals(authManager.getUser());
}
You're welcome. That was one of the first intentions I added to IntelliJ, and I use it all the time.
ReplyDeleteThat's so years ago. Eclipse stole that feature from IntelliJ aaaaages ago.
ReplyDeleteHi Howard,
ReplyDeleteIDEA has @NotNull/@Nullable annotations that are even cooler.
If you use those, IDEA will warn you while you type that authManager.getUser() may cause a NullPointerException.
I've noticed that, and I generally code to a don't allow null / don't return null philosophy. But here we're dragging in Hibernate ...
ReplyDeleteAnyway, I haven't been using those annotations because I'm trying to minimize the number of external dependencies for Tapestry. There's already plenty!
In Groovy, wouldn't this be
ReplyDeleteauthManager.user == blog.owner
... because null can be messaged safely (like good old Objective-C).
Good to see you already know about those annotations. Not only do they force developers to think about the input/output but it also documents them for other developers so they know straight away if they are allowed to pass null into a method and what they can expect in return.
ReplyDeleteGot rid of NPE's altogether in my projects :o)
But I do agree that minimizing the number of dependencies is a good thing.