21–30 of 230 posts
This is perfectly legal code, where the optional wrapper itself is null:
Optional getMiddleName() {
return null;
}Earlier quoted context omitted.
I can't think of any popular language that would take more than a few days to get acclimated to as an experienced developer, so that's not a very compelling argument.
Well, C and Scala are some counter examples that immediately come to mind. Kotlin is probably more similar to Java than any other mainstream language. There’s almost no learning curve there, while going from Java to other “easy” languages like Python requires significantly more time to get used to.
This is just covering up design problems. NPEs show you were you have design deficiencies. If you have getAccount().getContact().getPhoneNumber() and contact is null, you'll get an NPE. The question shouldn't be: "How do I shove the NPE under the rug for the next 1337 coder to deal with?", the question should be: "How did I initialize an Account without a Contact?"
It's so sad that Java 8 had the chance to really fix the null problem, but gave us only the half-assed `java.util.Optional `. Rather than implementing optional values at the language level, it's just another class tossed into the JRE. This is perfectly legal code, where the optional wrapper itself is null: Optional getMiddleName() { return null; }
This is just covering up design problems. NPEs show you were you have design deficiencies. If you have getAccount().getContact().getPhoneNumber() and contact is null, you'll get an NPE. The question shouldn't be: "How do I shove the NPE under the rug for the next 1337 coder to deal with?", the question should be: "How did I initialize an Account without a Contact?"
Well yeah that's exactly what static analysis can tell you - what code path led to that.
You're saying this project should be what it already is.
Or use Kotlin, it's near perfectly interoperable with Java and the acclamation period is measured in weeks if you're a Java dev
I can't think of any popular language that would take more than a few days to get acclimated to as an experienced developer, so that's not a very compelling argument.
This is just covering up design problems. NPEs show you were you have design deficiencies. If you have getAccount().getContact().getPhoneNumber() and contact is null, you'll get an NPE. The question shouldn't be: "How do I shove the NPE under the rug for the next 1337 coder to deal with?", the question should be: "How did I initialize an Account without a Contact?"
Static analysis (detecting) is the opposite of "covering up".
> "How did I initialize an Account without a Contact?"
As long as your language lets you do it, your teammates will do it. And in many cases it won't be accidental either. Your teammate will want an Account with its Contact set to null.
It's so sad that Java 8 had the chance to really fix the null problem, but gave us only the half-assed `java.util.Optional `. Rather than implementing optional values at the language level, it's just another class tossed into the JRE. This is perfectly legal code, where the optional wrapper itself is null: Optional getMiddleName() { return null; }
They couldn't have fixed it while retaining backward compatibility.
It's so sad that Java 8 had the chance to really fix the null problem, but gave us only the half-assed `java.util.Optional `. Rather than implementing optional values at the language level, it's just another class tossed into the JRE. This is perfectly legal code, where the optional wrapper itself is null: Optional getMiddleName() { return null; }
Don't people use @NonNull everywhere now? It's been a few years since I've programmed in Java but even then I feel like that was common practice.
It's so sad that Java 8 had the chance to really fix the null problem, but gave us only the half-assed `java.util.Optional `. Rather than implementing optional values at the language level, it's just another class tossed into the JRE. This is perfectly legal code, where the optional wrapper itself is null: Optional getMiddleName() { return null; }