public String getPostcode(Person person) {
if (person != null) {
Address address = person.getAddress();
if (address != null) {
return address.getPostcode();
}
}
return null;
}
Code language: Java (java)if (null != object) checks to avoid NullPointerException. Java 7 (Codename: Dolphine) will change the way we do Null handling in our code. Java 7 will be released in first half of 2010. If we write above code using Java 7 Null-safe Type (also called Null-ignore invocation), it will look like: public String getPostcode(Person person) {
return person?.getAddress()?.getPostcode();
}
Code language: Java (java)if (null != object) checks in Java 7. Java URL Encoder/Decoder Example - In this tutorial we will see how to URL encode/decode…
Show Multiple Examples in OpenAPI - OpenAPI (aka Swagger) Specifications has become a defecto standard…
Local WordPress using Docker - Running a local WordPress development environment is crucial for testing…
1. JWT Token Overview JSON Web Token (JWT) is an open standard defines a compact…
GraphQL Subscription provides a great way of building real-time API. In this tutorial we will…
1. Overview Spring Boot Webflux DynamoDB Integration tests - In this tutorial we will see…
View Comments
This was rejected by Project Coin.
See
http://blogs.sun.com/darcy/entry/project_coin_final_five
Wow !! Its looks great. Certainly helpful.
@ Stephen Colebourne: Can you provide more details for rejection?
This is the way Freemarker handles Null. In Freemarker you can go like:
( object.getThis().getThat() )?
I believe that the opinion is that it would promote the use of null, which is 'a bad thing'. Personally, I'm more pragmatic and think that avoiding loads of NPEs justifies the change. I know I would have used it all the time. If you don't like the decision, write to the Coin mailing list.
I do not like this. This makes it very difficult to read there is an null check and people will most likely over use it. There are times when it's valid to do a null check and there are times it's simply hiding a bug elsewhere. Also, during debugging, it would make it difficult to know which value is null.
Yes, it was rejected. Whilst it makes sense in Groovy, when actually tried out with real Java codebases as part of project coin testing, it didnt work so well compared to the Groovy implementation. Who knows, if you want it, contribute to the project.
Javaposse interview with Project Coin is a great resource about the how and why http://javaposse.com/index.php?post_id=529403
I would strongly recommend Viral puts an Edit at the top of the article per Stephan and Stefans comments.
Null safe checks are useful in large legacy codebase. I personally prefer to fail fast with liberal use of preconditions to fail early in a method call however different processing needs have different requirements.
This syntax is horrible and I cant thing of something better.
I do think of C++ and the -> Operator
public String getPostcode(Person person) {
return person->getAddress()->getPostcode();
}
Or potentially use the .. operator (my own concoction)
public String getPostcode(Person person) {
return person..getAddress()..getPostcode();
}
Both seem horrible because of c++ nostalga and general eyesore.
I am facing the compilation if i do the same and try to work out.
Can you please help me out??