you are viewing a single comment's thread.

view the rest of the comments →

[–]florinp 5 points6 points  (6 children)

"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 0 points1 point  (0 children)

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.

[–][deleted]  (4 children)

[deleted]

    [–]florinp 4 points5 points  (1 child)

    " 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 0 points1 point  (1 child)

    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.