3 ms·

I have been writing Java for money for more than ten years and never ever have I had non-trivial problems with null. Less than one percent of the bugs I fixed w

I have been writing Java for money for more than ten years and never ever have I had non-trivial problems with null. Less than one percent of the bugs I fixed were caused by nullpointers, less than one percent of write-deploy-test loops were caused by it. I either have code that can't be null (e.g. getters of lists that create a list if the field is null, outright validation before usage), code where null has a desired meaning that must be handled (new JPA entity with no key yet) or code where the Nullpointer will lead to a client/user/implementor caused bad request style response. What the hell are you guys doing for you to spend significant amounts of time on NullpointerExceptions? On the same note, I didn't understand the inclusion of Optional in Java. Always felt like some annoying special flavor type of custom Java nuisace like vavr or jooq.

rightbyte 4y ago
Null pointer exceptions are like free unit tests. The programmer assumed something never signaled an invalid result and was wrong. I don't understand the fuss either. Logic problems from improper error handling is way worse than NPE. Edit: Pointers that can be null actually are a sum type but without the fancy pants hype.
justin_oaks 4y ago
There are patterns that experienced developers will use to avoid issues with nulls. Here are a couple off the top of my head. 1) Reversing string comparisons: "literal".equals(variable) instead of variable.equals("literal") 2) Always initializing lists instead of leaving them to default to null public class SomeClass{ private List someList=new ArrayList(); //or Collections.emptyList() ... } The problems with NullPointerExceptions can mostly be solved by teaching programmers to use these strategies and teaching them to look for boundaries where nulls can slip in. The real problem happens when things get scaled up. If you have thousands of developers then it makes sense to take steps to automate the problem away. Also, if the code is used by billions of users then even rare NullPointerExceptions will happen frequently. So it makes perfect sense for Facebook to be the one to work on this.
- ben7799 4y ago
  The funny thing is these techniques were introduced in books like "Effective Java" before many of the developers who complain were even born. Everyone should know these things by now. They are good things to ask about in interviews.
ahtihn 4y ago
> On the same note, I didn't understand the inclusion of Optional in Java. It interacts nicely with stream pipelines.
ben7799 4y ago
Way too many developers are lazy and haven't actually studied the language they're using to adapt their code. So instead you get discussions where the tools are blamed. Obviously there are a lot of lazy/bad developers and the larger the company/team the more likely you have some of them. The irony is when this comes up in discussions about places like Google and Facebook that have built up a cult of believing they are better than everyone else while seemingly having lots of trouble dealing with these kinds of issues. I don't hate Optional, but what I find is the same people who can't handle using null also fall into the Optional anti-patterns.
mrkeen 4y ago
The slow-down doesn't come from NPEs occurring as bugs. The slow-down occurs from all the extra thinking that happens once [your teammate] allows nulls into the code "as a feature". If you assume no nulls, then you get to lean on the type system. A String is actually a String, not an instruction to GOTO the nearest enclosing RuntimeException handler. And honestly, I'd be mostly happy to work on the no-null assumption, hit a few NPEs, and fix them as I go. But someone else will decide that nulls are OK as values, and now every value is suspect. Which means you can no longer just blindly assert against nulls. And that's the value-add of Optional. You can use it to deliberately represent things that aren't there, meaning you can go back to treating every null as a bug to squish, rather than a design choice.
mrcrumb1 4y ago
If only there were a language feature that could tell you which case it was and ensure you handled it correctly...

rightbyte 4y ago

Null pointer exceptions are like free unit tests. The programmer assumed something never signaled an invalid result and was wrong. I don't understand the fuss either. Logic problems from improper error handling is way worse than NPE. Edit: Pointers that can be null actually are a sum type but without the fancy pants hype.

justin_oaks 4y ago

There are patterns that experienced developers will use to avoid issues with nulls. Here are a couple off the top of my head. 1) Reversing string comparisons: "literal".equals(variable) instead of variable.equals("literal") 2) Always initializing lists instead of leaving them to default to null public class SomeClass{ private List someList=new ArrayList(); //or Collections.emptyList() ... } The problems with NullPointerExceptions can mostly be solved by teaching programmers to use these strategies and teaching them to look for boundaries where nulls can slip in. The real problem happens when things get scaled up. If you have thousands of developers then it makes sense to take steps to automate the problem away. Also, if the code is used by billions of users then even rare NullPointerExceptions will happen frequently. So it makes perfect sense for Facebook to be the one to work on this.

ben7799 4y ago
The funny thing is these techniques were introduced in books like "Effective Java" before many of the developers who complain were even born. Everyone should know these things by now. They are good things to ask about in interviews.

ahtihn 4y ago

> On the same note, I didn't understand the inclusion of Optional in Java. It interacts nicely with stream pipelines.

ben7799 4y ago

Way too many developers are lazy and haven't actually studied the language they're using to adapt their code. So instead you get discussions where the tools are blamed. Obviously there are a lot of lazy/bad developers and the larger the company/team the more likely you have some of them. The irony is when this comes up in discussions about places like Google and Facebook that have built up a cult of believing they are better than everyone else while seemingly having lots of trouble dealing with these kinds of issues. I don't hate Optional, but what I find is the same people who can't handle using null also fall into the Optional anti-patterns.

mrkeen 4y ago

The slow-down doesn't come from NPEs occurring as bugs. The slow-down occurs from all the extra thinking that happens once [your teammate] allows nulls into the code "as a feature". If you assume no nulls, then you get to lean on the type system. A String is actually a String, not an instruction to GOTO the nearest enclosing RuntimeException handler. And honestly, I'd be mostly happy to work on the no-null assumption, hit a few NPEs, and fix them as I go. But someone else will decide that nulls are OK as values, and now every value is suspect. Which means you can no longer just blindly assert against nulls. And that's the value-add of Optional. You can use it to deliberately represent things that aren't there, meaning you can go back to treating every null as a bug to squish, rather than a design choice.

mrcrumb1 4y ago

If only there were a language feature that could tell you which case it was and ensure you handled it correctly...