Null Object: Something for Nothing (2003) | Hacker News Reader

Null Object: Something for Nothing (2003)

researchgate.net

10 pointsfurikuri17 comments

I'm surprised* there's no mention of Objective-C's behavior when passing messages to nil. Nothing blows up; the message either returns 0 or an empty struct, depending on its return type. In actual practice this can sometimes result in weird behavior, but overall I always thought it was a very humane feature of the language.

*Well, ok, not /that/ surprised, given the year of publication, but Objective-C did at least exist at the time.

That seems like a bad idea. It potentially moves the failure further away from the cause. It's nearly always better to fail fast and deal with the problem, than propagate. Obviously it'd be even better to not have null at all, or have a null that doesn't claim to honour a contract that it can't fulfil (Option/Maybe type basically).

For C# programmers I attempted to help fix the problem[1] (it papers over the cracks):

[1] https://github.com/louthy/language-ext

In Objective-C, you generally don't treat messaging-to-nil as a failure but a common occurrence. It's a different approach to API design, really.

I write much more Obj-C than Java, and I'm always kind of surprised going back to Java that null is such a big boogaboo all over the place. Considering how much influence Obj-C had on Java, it's a shame Sun didn't adopt "benevolent nil".

It seems a little odd to write code intending for it to do nothing. If that isn't a recipe for obfuscation...

It fits the tenets of OOP though, you ask an object to perform an operation, the "null" object just ignores the request.

I'm probably full of crap about this.

If you wrote "a = b/c" it would be silly to complain that this operation 'does nothing' whenever b == c happens to be true, so by analogy, it's not too farfetched to think it's useless to write code that does nothing when given a null object.

On the other hand, multiplication and division are standardized and familiar operations. Object semantics differ for each kind of object, and it may not make sense to allow null objects for everything, and if you need one, you can always implement it later.

So it really depends on what you think the tenets of OOP are, and that's not a cut-and-dry question.

I think the obvious right answer is to not have null in the language, and use an option type instead. There might be a better solution, but I haven't come across one yet.

Of course, it's too late for Java now. They have an Optional<T> type, but removing null from the language would break backwards compatibility. Of course, that means that a method that returns Optional<T> might return an Optional<T>, or null, so now you have 2 things to check instead of one :).

It's not a full solution, but java has support for nonnullable annotations so under certain situations the compiler will guarantee that you don't need to check for null. Backwards compatibility's a PITA.

http://types.cs.washington.edu/checker-framework/current/che...

Yeah, I've looked into that, but you have to use their special compiler to build. I can't find a way to use it in a Maven build that doesn't require the user to install the checker framework locally.

> There might be a better solution, but I haven't come across one yet.

An Option type (and/or an Either type as well) is a good base, but if you can create a null object itself it's still better.

Can you elaborate?

Heh, maybe Java 9(10? I have no idea what number they are currently working on) could forbid types that return Optional<T> from being null.

Java 10 is supposed to introduce value types, that will change the way we use nulls, check here: http://blog.joda.org/2014/11/better-nulls-in-java-10.html

> Of course, that means that a method that returns Optional<T> might return an Optional<T>, or null, so now you have 2 things to check instead of one :).

NO. Just don't check for null and let it fail -- that will uncover a bug, namely using `null` when they should have used "None" or whatever it's called in Java.

Do people defensively check for null for every object access in java? I hope not, because that would be really tedious and obfuscate all logic bugs relating to inappropriate uses of null.

The problem with not checking for null is that it won't fail soon enough. null will get passed along until someone tries to call a method on it, at which point you'll get a NullPointerException. But at that point you don't know where the null came from. It's better to fail early.

Lombok can help with this, with its @NonNull annotation, but that only helps so much.

Do you assert that all object variables that cross an interface boundary are not null (`assert var != null`)?

OOP Java-style: nothing comes easy, everything is a pattern.

Reply on news.ycombinator.com