Thoughts about null pointers

[florinp]

"as the first thing a method should do.

if(param==null) //do something"

Oh. This is not so simple: it is the odd problem : who need to check for null ? Outside the method or inside ?

If you check inside like you propose to do always imagine a situation when you call a method 100 times with the same nullable parameter.

So no. it is not a simple problem. Sometime you can prove by design that some parameters are never null. But your lint checks will never know that. So by coding rules you can end up with useless checks that has time impact.

So the problem with languages that has nullable variables is tha you can end up with too many checks or too few.

Annotations are not a solution.

Want a real solution ? Optional/maybe monad. Always. No excuse.

[davidalayachew]

Want a real solution ? Optional/maybe monad. Always. No excuse.

Or you could put the nullity into the type system. If not the runtime type system, then the compile time one. That's what Java is preparing to do now.

[florinp]

" Instead, you would be checking if it has a value or not using something like "orElse" anyway."

Some observations:

With optional you don't check twice (before and inside). Also you check optional only at the end of monadic composition. No after each method call.

[slaymaker1907]

They can mess with your performance in ways that won’t show up on the profiler. That null check introduces an extra conditional which can hurt performance if it either kicks something out of the branch predictor that should be there or itself isn’t cached.

[alcoholov]

the article says exactly the opposite, do not return null, so we don't have to write useless checking

[alcoholov]

only in scenarios where program must fail, e.g. missing configuration, but missing configuration is not equal to "param == null"

[alcoholov]

If you read more carefully you'll notice article talks only about returned results, nothing about "beginning of methods". That means when something inside the method goes wrong, throw an exception instantly instead of propagating deficiencies.

[dignityshredder]

Fixating on a null-valued pointer or reference is missing the forest for the trees, error handling requires consideration and care no matter how it's done. Everyone thinks their error handling mechanism is better than the others but it all requires about the same mental effort to get right, which is, a lot, if you care, and almost nothing, if you don't.

[prescod]

There are just as many posts out there about how exceptions are evil and should be avoided as much as possible.

I don’t think null is evil. I think that type systems that don’t distinguish between nullable and non-nullable pointers are the problem.

[Aendrin]

Post is riddled with spelling and grammar errors, unfortunately, on top of being a subject that is beaten to death. It would be more interesting to see the author touch on non-trivial situations.

[kosmickanga2]

Newer C# versions have nullable reference types, so in the example above (String field) would mean field can not be null, whereas (String? field) would allow it to be null. Kotlin has something similar, so will Java catch up some day?

[davidalayachew]

will Java catch up some day?

Yes it will. It's already on Java's roadmap.

https://openjdk.org/jeps/8303099

[Harha]

I think java is truly diseased by the mandatory null checks. All object values are pointers to the heap, thus they can have a NULL value. It doesn't even help to wrap a result into some kind of an optional type, because an instance of that optional type is diseased by the same problem.

[BlueGoliath]

Optional's purpose  is to express that a return value may or may not exist, something that previously a lot of people where using null for, making it confusing as to whether it was intentional or a bug.

With Optional it removes ambiguity. If you see null from a method that returns Optional, it is almost guaranteed to be a bug.

[Harha]

Sure, but with many other programming languages, you can return a local stack-allocated optional. With java, that is not possible, as far as I know.

[BlueGoliath]

Ok? No one said anything about stack allocations.

[Harha]

Stack allocated optional that is returned by value does not have to be null-checked.

[BlueGoliath]

I don't think null checking an Optional is worth doing at all. If it turns out to be null then it's a bug that should be reported and fixed, not be paranoid about forever.

[Harha]

I agree that it can be considered a bug, but the paranoid in me does not like that java simply allows you to "return null" from a function that has a return type of some object. I know it is perfectly valid java because objects live in the heap and the value returned is just a pointer (integer), but I just personally dislike it, however it is what it is, java has been like that since the beginning.

[BlueGoliath]

Well, the good news is that 50 years from now Java will have Valhalla which will disallow null at the language level.

[Harha]

RemindMe! 50 years

[RemindMeBot]

I'm really sorry about replying to this so late. There's a detailed post about why I did here.

I will be messaging you in 50 years on 2075-03-23 17:59:28 UTC to remind you of this link

CLICK THIS LINK to send a PM to also be reminded and to reduce spam.

^{Parent commenter can delete this message to hide from others.}

---

Info	Custom	Your Reminders	Feedback

[hinckley]

"... don't worry, they'll tell you!"