Oscar Ablinger

Which problematic cases?

Even a simple Map with a null value. You will fail in runtime regardless of a compiler feature.

About the code you posted. Notice that some null validations are enforced by the frameworks too. E.g. bean validation, etc.

However, this is a mistake. Why do you need to check if a value is null???

Just let it propagate and fail when you try to use the variable.

Or in the case of String as you did here:

return doFoobar(foo.toString(), bar.toString());

I mean having the support is free, but actually using it isn't. I don't get how that's a win for null?

Exceptions are rare. We optimize for the common case. If something is fast except for the 1 in 1000 case then its fast.

I can catch NullInDatabase nicely. Catching a NPE is risky since at any time more code could be added that throws this exception with entirely different semantics.

And what would you do for that catch? Do you have a fallback plan for that?

I get what you're saying but if you have a way to handle NullInDatabase then you would do it where the failure happened not in the catch.

Typically in a Spring application you just let the exception bubble up and have a generic exception processor return a proper error response to the rest request.

With nonnullable-as-default the programmer is forced to deal with it. ... e.g. using some default value or rejecting only that record instead of the entire batch

I get that claim but I think it seems good on paper only. You don't really have a recovery mode for nulls in most cases.

The problem is exactly this. The non-null compiler feature shows you something that "might" be null. So you spend time building logic to deal with this failure. This goes against the fail-fast principle. You spent time writing logic that doesn't fail when there's a problem.

But if your logic throws a custom exception then you invented yet another way to fail. That NullInDatabase doesn't provide any real world benefit over a generic NPE with a stack trace.

Yes, the language cannot check it, but it can force you to check it and in the process prevent errors that would otherwise be overlooked.

This is the source of our disagreement. I think it forces us to check it and as a result we write more code and add more places where we can fail. I think failing simply in a generic way is usually the best approach.

Shai Almog

Even a simple Map with a null value. You will fail in runtime regardless of a compiler feature.

Oh you meant if you tack it onto Java via its annotations. Then yes, that has a lot of limitations, but that's also why I think it's such a shame that Java wasn't designed with it from the ground up. In e.g. F# you can have a map like Map<string, string option> which means that "null" values are allowed as a value but not as a key.

It's still compiled to the same as a Map<string, string> in C#, but it provides compile-time safety.

However, this is a mistake. Why do you need to check if a value is null???

Just let it propagate and fail when you try to use the variable.

Because of the fail-early principle? We want to fail as early as possible. Otherwise I'll have to move up the stacktrace to find out why the value could be null. In this case I know it was the caller of that method. That saves a lot of time not just if I have to correct it, but also if e.g. the calling code is owned by a different team.

It also helps prevent unexpected states when methods suddenly interrupt in the middle of it's execution due to a NPE. Yes, you should be able to handle it (e.g. transactional logic if necessary), but by checking it earlier I can rely on it afterwards when using it, resulting in cleaner and faster code. It's also easy to overlook places where transactional logic is required.

Exceptions are rare. We optimize for the common case. If something is fast except for the 1 in 1000 case then its fast.

Yeah, it's not a big issue, but I don't see how that's a win for null.

Also, a 1 in 1000 case in Java actually has a performance impact on the other 999 as the runtime realizes that the fast path is not reliable and cannot use the optimistic nullness assertions. Most programs don't have to care about such minimal performance gains, though. I just wanted to mention it since most people don't know about it.

And what would you do for that catch? Do you have a fallback plan for that?

I get what you're saying but if you have a way to handle NullInDatabase then you would do it where the failure happened not in the catch.

Sometimes, I want to handle it where the failure happens. Then I wouldn't throw an exception. But if I cannot handle it, then I'll have to throw an exception and I believe that sometimes a specific exception is preferable to a generic one.

Let's say I call a method that should send some data to the database. If I get a NPE it could be because I gave it invalid data, the method is implemented wrong, a connection cannot be established, something in the database is null, a configuration value is null etc.. I'm mostly interested in whether or not it's my fault. With a specific exceptions I immediately know it, while with a NPE, I'd assume it's the fault of the one where it happens. But maybe it's the callers fault or another component that it depends on returns null even though it shouldn't?

You don't really have a recovery mode for nulls in most cases.

Yes, because most of the times it's a programming error. Most of the times the "recovery" is "tell the programmer to fix it". And that happens by looking at the code, figuring out why it can be null and what to do in that case. Most of the times that means find out who returns or provides a null value in a place where they shouldn't.

With nonnull-by-default that happens before an error happens. Oh the method doesn't accept null? Then I have to handle it. Sometimes that means using a default value, sometimes that means failing. But I notice it when writing the offending code not when going through my log lines.

The problem is exactly this. The non-null compiler feature shows you something that "might" be null. So you spend time building logic to deal with this failure. This goes against the fail-fast principle. You spent time writing logic that doesn't fail when there's a problem.

Noone says you're not allowed to fail when you see a null. But it becomes explicit. And when reading the code I immediately know that it's an option. More importantly, when writing code in a language that has nonnullable types, I don't have to ask all the time "can this be null?" and make sure it doesn't fuck anything up if it is or "can I use null in there" and look through the entire method to see if it handles it correctly (which might even change in the future without me knowing).

The annotations and requireNonNull are bandages for a lot of these problems and still allow Java to scale to enterprise size. But I don't see the advantage over having it baked into the language itself.

Oscar Ablinger

It's still compiled to the same as a Map<string, string> in C#, but it provides compile-time safety.

Yes but you can't use that for external data source and going over all the entries.

However, this is a mistake. Why do you need to >> check if a value is null??? Because of the fail-early principle?

Yes. I'll need to move up the stack. But it also saves me from replicating and keeping stuff that's no longer relevant.

Case in point. I have code that currently doesn't deal with variable X being null. If I add an explicit check at some point that fails immediately then even if I fix the code the failure (that's no longer needed) will still happen.

I want to see the "real failure" when it's possible. A validation should have a reason.

Yeah, it's not a big issue, but I don't see how that's a win for null.

I consider the performance natively on the CPU to be a win. Some things in non-null cases can be compiled to null. But some can't and this isn't clear from the language. That's the win.

Also, a 1 in 1000 case in Java actually has a performance impact on the other 999 as the runtime realizes that the fast path is not reliable and cannot use the optimistic nullness assertions.

Not so much. Since the exception is an interrupt there's really no change for most cases. The exceptions are rare, if this actually does happen the JIT just removes that optimization.

Let's say I call a method that should send some data to the database.

I understand what you're saying. But did you ever write code like that???

I have code that retries, that's a common case. But writing an entry to the database is VERY specific. I can't just write generic code that catches the case and does something differently. I generally would write if(x == null) ... within the same method.

But it becomes explicit

This is a fair point. But I don't think it's a necessary one. It pushes us to overthink null situations in some cases and write more code instead of just failing at runtime.

I get that failing at runtime is "the worst". But for a vast majority of the cases it's the right and simplest thing to do. It's then easy to fix.

Anyway, I think we're getting to the point where we keep repeating the same thing. This is an interesting discussion though, so thank you. I'll let you have the final word if you think more needs to be said.