Hacker News new | past | comments | ask | show | jobs | submit login

Aren't you just shifting the problem rather than solving it?

For example, let's say I am calling a function which returns an object:

       var myStuff = new GiveMeStuff().GenerateStuff(1337);     
The return of this value can be valid "stuff," an exception, or null. If we remove null as an option, what happens when internally an exception is thrown within GenerateStuff()? Does it re-throw that exception? Or do we now need a property within stuff like (bool)myStuff.validStuff?

Null is a very useful way of communicating something failed. It is useful firstly because it is a "cheap" comparison and secondly because it saves us from having to place try{}catch(){} blocks around all of the things.

So my question is: without null how are we communicating failure? More exceptions? Or more clutter within our objects.




Null values don't go away, it's just that reference types aren't by default nullable. Your function can still return null (if you really want it to) as long as that is indicated by the return type. What you can't do is directly assign the possibly null return value of your function to a non-nullable reference.


Languages like Haskell, Swift, and Rust use an optional type[0] for nullable things. Most things don't need to be nullable, and by being explicit about it in your type you convey your intent - ie. 'this thing might fail, and you must handle it if it does'.

- [0]: http://en.wikipedia.org/wiki/Option_type





Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: