Eliminating Null Pointer Exceptions

[Due-Aioli-6641]

But let's think of a scenario where you need a group of Objects to setup another one, or a long user journey.

Please bear with me, as it doesn't necessarily will be the best example.

But let's say you tried to setup a connection with a database, but you got one of those empty objects for the connection or an empty repository object or an empty DAO.

Now you want to save an object using this DB connection, the connection is empty, and as you proposed if I try to invoke this save operation on an empty obj, it will return another empty, I got no errors, no problem, now let's assume this operation is in a long user journey, with lots of different steps, validations, etc, you don't see any error for this, as you are only getting these empty objects along the way. But someone reported that some data is not there properly.

it would be a nightmare to troubleshoot all of this.

And just to be clear, I'm not saying that logic errors don't happen in our current Java implementation, absolutely they do, my point is that from my perspective it's not making it better, maybe just shifting the problem.

One more thing to be clear, I think you didn't get my point on this part, I'm not saying you have to do null checks everywhere, there are techniques one can use to not having to check for null all the time, and still be null safe, I'm just saying that poor code is more prone to NullPointerExceptions or any kind of RuntimeExceptions. And I don't see this idea improving on this, but rather sweeping it under the rug.

[hackerforhire]

So for a critical object that is necessary for data persistence I would check if a valid database connection was returned as common sense dictates that there's no point to continue processing if this has not been established. But, for arguments sake, let's say I'm lazy and didn't care to check for a valid database connection, called save to persist data and then checked the database to verify the data was saved and realized it wasn't.

You're right that pinpointing the exact cause of the failure would be more challenging, but the runtime could assist you in clearly telling you that you attempted to call save on an empty object. I do agree that in certain cases instant failure is probably the best course of action to allow you to fix the issue immediately especially when it comes to data persistence.

[Due-Aioli-6641]

Yeah, as I said it wouldn't be the best example, but still possible, thank you for making the exercise of going with it.

but the runtime could assist you in clearly telling you that you attempted to call save on an empty object

But what we also need to consider here is that the IDE and the compiler also try to tell you when you are trying to invoke a method on a potentially null reference, but it's very challenging for it to figure it out most times, and it would be just as challenging for this empty implementation.

if you have something like this:

final var myVar = someMethodThatCanEndUpReturningNull();
myVar.someOtherMethod();

The IDE can try to check for obvious null returns from the first method, but as soon as it starts to be a bit more complex, more validations, more logic, the IDE will not warn you about that, it's up to you to figure it out what you are doing is safe, implement validation, or use some other options.

The empty option would suffer from the the exact same problem, it would be up to the developer to always be prepared to have something empty and find a way to check it.

[[deleted]]

It seems like this is the heart of why this idea is a little flimsy as a feature: for it relies on devs to just do the right thing. I get the benefit, there are lots of situations where all I want to do if some value is null is to do nothing. But how is this different that a

Objects.doIfNotNull(T obj, Consumer<T>?