Comment by latencyloser | Hacker News Reader

Comment by latencyloser | Hacker News Reader

Parent Full thread

I write Java daily, I haven't seen one in a production environment in... at least recent memory. Most common NPEs I've seen can be resolved by doing two things: 1) for returning a single, nullable value, wrap it in Optional. 2) Never return null collections, always default to an empty collection instead.

More nuanced ones can often be caught by using all args constructors and requiring the constructor values with Objects.requiresNonNull() or similar. Using spring? Don't use field or setter injection, always constructor so the above applies as well. Making the state of your objects largely immutable means their state is more consistent and what is null and when becomes a lot less surprising.

Lastly, write good tests. If you're exhausting the behavior of your system with tests, these things are much less likely to surprise you later.

NPEs are definitely a problem with Java, but they're a very avoidable one as well.

Edit: I don't understand the downvotes. The parent said they're a huge deal and I'm disagreeing because I think they're relatively simple to avoid?

> I think they're relatively simple to avoid?

Most issues in software fall into this category, though. The issue with Java’s null is that it’s not type safe. The language is generally a strongly typed language, except in the case of null. And until Value Types land, there is no way to express nullability to the compiler.

The arguments you make aren’t all that different than the undefined behavior arguments with C. “Just follow these simple rules and you’ll avoid all issues”, a compiler should do that for you IMO.

I can’t wait for Value Types in Java, at that point we can have real Option types.

Right.

No downvote, but GP post conflates "how code SHOULD be written" with "how existing code was written" in my opinion. Same with one of the earlier comments about "idiomatic C++ does bounds checking." I've seen plenty of NPEs in real, working Java.

If Mozilla isn't managing to write idiomatic C++, I don't hold out much hope for myself either.

> “Just follow these simple rules and you’ll avoid all issues”, a compiler should do that for you IMO.

This was one thing I really liked about Kotlin vs Java. It's nice that my IDE can do the work of generating getters/setters on a POJO for me, but it's not nice that the language requires me to fill my source code with that noise. To a first approximation, any task rote enough the computer could do it for me, it should not ask me to do.

See also: static languages that don't offer type inference.

this is just an honest question, and i’m genuinely curious, but why couldn’t Optional<T> be done as an immutable reference type... why does it need value types to be implemented first?

do you mean like a final field in an class?

i was thinking something like that, yes

It’s still not a “guarantee” that it’s not null, but you can be somewhat more confident that it isn’t if you assign it in all constructors of the type.

For params and return values you still can’t know for sure, and in all these cases it -could- be null. But yes, making all fields and variables that are Optional would help as a coding practice, except of course where you need to reassign the value in the Optional, as there is no “set” on the type.

Rust basically just enforces the things you mention

With the cost of catching up to 25 years of tooling and libraries.

We’re getting there. I dislike this argument, I’m sure the same was made in favor of C when Java came out.

I agree with you, it is just a call to reality to those "lets rewrite everything in language X", without consideration that there is more to it than just grammar and semantics.

Also there are plenty of domains where Java or C++ aren't even taken into consideration, in spite of decades of effort.

Just to cite Microsoft's recent security recommendation out of Blue Hat conference, regarding their own software, "use a mix of C#, Rust and constrained C++".

Can also use checkerframework to statically analyze your code for NPEs. It effectively augments the type system to require you to handle nulls where appropriate. It doesn't recognize I/O boundaries for you, you have to make sure those are annotated properly, but after that with sensible defaults, you can be more confident of the NPE-free-ness of your code.

I suppose that you are being downvoted because, though your arguments are correct, this thread is not about "how to avoid NPEs in Java" and is therefore OT.

That said, "write good tests" is impossible. You can write as many tests as you want, you can make sure those loops loop or don't, and those ifs if or don't, but you cannot write "good" tests. Tests will always miss some corner case, some input, some unexpected locale variable.

NPEs literally The Billion Dollar Mistake, and you don't think they are a big deal?

https://www.infoq.com/presentations/Null-References-The-Bill...

In my experience null pointers and unassigned variables were a big problem in C an C++. But in java? They were never something that really caused a major issue. Most of them turn up in tests and are really easy to fix because you get an exception stack. Very few turn up in production and often it is because something else failed at runtime to cause it. If the null pointer wasn't there you would have had to deal with that other failure anyway.

Reply on news.ycombinator.com