To the developer who introduced the NullPointerException.
Thank you for nothing!

May I ask why...

*🍿*

@IntrusionCM when it gets introduced into a code source by a ball head, it can be frustrating for others who are working on the project because most of the time it prevents the program from working as intended leading to invisible bugs, and the other guys will have to spend extra time trying to fix an error which could have been prevented from the get go.

@GiddyNaya hm, interesting.

Mostly it is to prevent to bugs?

E.g. Objects.requireNonNull?

Do you have an example. Just curious

I feel like the NullPointerException not being there wouldn't be better. The code would still be shit you just wouldn't notice.

@IntrusionCM you already answered the question.

String abc = null;

String xyz = "";

String xyz = Objects.requireNonNull(abc);

This will throw an NPE at runtime. Now imagine If it was wrapped inside a try-catch block along other pile of codes without any fallback logic... the code will probably work but then you get unwanted outputs because a null value sneaked in causing havoc which could have been avoided through checks like: "if xyz != null then..."

This same reason brought Kotlin into the picture.

@GiddyNaya I'm curious in what situation this actually happens though, apart from your abstract example.

@PotatoCookie Read this if possible:

https://wiki.sei.cmu.edu/confluence...

@GiddyNaya Hmm yeah it's an interesting read and I think I half misunderstood your viewpoint on the situation in your first message.

Anyways I do believe a good codebase would not have this as a blocking issue because... You should design your code properly to avoid such iffy scenarios.

I agree with the solutions in this example (screenshot) and I don't really see anything wrong with it. The exceptions should just not occur by proper code design or be allowed to occur in a way that serves their purpose correctly (e.g. fail-fast principle).

There is a reason why the inventor of null references calls them his million dollar mistake.

A better real life scenario would be like:

Imagine your user bought a ticket to a show via your app. They got a success message! The day of the show finally arrives, happily they left work early, arrange their babysitter to go see the show. When they arrive at the venue they discovered they don’t have tickets! and there are no empty seats available.

Yeah you can safely guess why because a NPE was caught.

@GiddyNaya

Ah ... I see.

I'm not trying to be smarty pants, though it might sound like I am...

The confluence article goes into great detail, but the first lines are the most important ones.

"Handling the underlying null pointer dereference by catching the NullPointerException rather than fixing the underlying problem is inappropriate for several reasons."

Your code example is perfectly valid.

Objects.requireNonNull was exactly made for that.

What is *not* valid is code like this:

Line 1: try
Line 2...N: <gobble gobble code>
Line N+1: catch(Throwable ...)

The code is dangerous. NPEs are least of your worries in that case.

If you look around, you might find comparisons of try / catch handling to go-to and the call to not use exceptions at all... Which is absurd, but just to point out how far wrong exception handling has gone. Not in just a few cases, but I see it at least once a month in a PR.

The interesting thing is that in this case, the NPE isn't the problem, the exception isn't the problem, the try / catch isn't the problem... It's the architecture.

It's code smell. One of the worst.

An exception should be specific, that's why one should define their own if applicable.

That is what many devs understand.

What they don't want to understand is that the same applies to try / catch clauses. Mostly for lazyness I guess.

I said it's an architecture problem - to explain, let's take your example.

Let's say...

class Person {
private final String name;
public ... (String name) {
this.name = Objects.requireNonNull(name);
}
}

Let's say that the Person model is handled inside a controller with a person service...

I see most often code like the above try ... catch clause that does *everything*:

HTTP Status Code Check
JSON Serialization Post Body - Person DTO
Person DTO - Person Service, store
Person Service, return ID
JSON Serialization of ID to response model

That's an architecture problem.

Someone just put everything into a mixer.

If one did it right, one would definitely separate the exception handling by the boundaries set.

E.g.

HTTP Status handling - first boundary, middleware provides exception
JSON Serialization - second boundary, JSON library provides exceptions plus exceptions of Person
Person service - third boundary
JSON Serialization of response - fourth boundary.

This does not just prevent a lot of possible nasty bugs, but it eliminates a lot of debugging.

NPEs or null isn't your problem. It's badly written error handling.

And the nulls are really the least of your problems.

E.g. if person service has transaction handling, this could lead to a lot of database funka doodle when reverting a non existent transaction.

Architecture problem - error handling has to respect the boundaries of library vs application or - if used - the boundaries of the domains.

@IntrusionCM very good explanation:) !

In my opinion, a state of the art language eliminates null pointer exceptions at compile time by not letting you potentially give null to code that can't deal with optionals.

This part of Java is seriously botched. And everyone copied the mistake. At least, Microsoft added compile time null checks to its languages after some years. But static analysis tools for Java exist and Java is one of the easier languages to statically analyze.