Why can't a Mono hold a NULL

Question

Mono.just(null) will not compile. Why is that?

On a procedural level I get it. It does not make sense to have a processing queue without something to process. Can someone phrase this for me with some more technical depth?

Biernat

Answer 1

As stipulated by Reactive-Streams, rule 2.13:

Calling onSubscribe, onNext, onError or onComplete MUST return normally except when any provided parameter is null in which case it MUST throw a java.lang.NullPointerException to the caller, for all other

And Reactor is based on the Reactive Streams.

Personally, I don’t like this rule, but the rule is not set by me. Since I want to use it, I can only follow it.

I guess Flux is the core of the Reactor, Mono is incidental. For streams, banning null is probably a reasonable option although it would be inconvenient for Mono.

Cyaneous

Answer 2

There are high risks when letting null into an application/library, and if you can ban it, one should.

Null is like letting a bomb into your application, if something potentially can be null, then something can explode with a NullPointerException at any time.

null creates an enormous uncertainty in an application at all times. You should always clean out null as early as possible.

People solve this by doing null checks, everywhere, which are basically redundant operations.

Sir. Tony Hoare - The inventor of null famously claimed that null was his:

billion dollar mistake.

There are plenty of programming languages out there that doesn't have null, here is a long list:

List of languages without null

Having null in a stream makes no sense as it also means that the reactor library would have to do null checks all over in their code to make sure that they don't try to do an operation on a null value. Everyone would have to do null checks in every flatMap, map, filter, operator etc because there could be a potential NullPointerException in all those operators.

So they had the opportunity to exclude null, which makes perfect sense, as null is not a value, and only values can be transported in streams, so that's probably why they decided against it.

Instead they decided to use a type Void to represent "nothing" which can be obtained by calling Mono<Void> nothing = Mono.empty(); which is type safe, will not explode if you touch it, and behave as you expect, since the developers control it, and not the runtime.

I would instead ask myself, why do you actually need null? i'm guessing because you have gotten used to it, aad coding out of habit is bad.

95% of the times i have seen null used, it could have been removed.

Learn instead how to code without null, make it a habit to use default values, fallback values etc. it will most likely make your program more robust, and more deterministic.

Modicum

I'm not here to fight for or against nulls so I feel your answer loosely relates to my question. I'm more interested in understanding what would happen downstream if you let nulls in. On framework level it's more pain but on user side it wouldn't be that much of a difference I guess. I'd still just call Mono.justOrEmpty() and treat it the same way as an empty (or Void) Mono, right? – Biernat

what would happen? you would most likely get a NullPointerException somewhere... and if they covered that, then they would have to redesign the entire api, to be able to handle null and implement new operators for it etc. Which they wont because as expleined before if you can avoid null you should, which they decided to do. Testing becomes easier, stability becomes better etc etc. – Modicum

Answer 3

The reason has already been explained by others, and Mono.justOrEmpty(null) exists to make you life a little easier, if you want the null to result in an empty Mono, but it needs to be a deliberate decision by you.

Bloodshed