Timeline for Are null references really a bad thing?
Current License: CC BY-SA 4.0
32 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 10, 2023 at 19:54 | history | edited | CommunityBot |
replaced http://bugs.sun.com/bugdatabase/view_bug.do with https://bugs.java.com/bugdatabase/view_bug
|
|
| Oct 24, 2023 at 10:34 | comment | added | Oliver Schimmer |
Most of the stuff here applies only to some languages (for example each reference type being a 'null-or-reference' type). Just because Java is especially bad at this, this is not a argument against null and in addition not even what Tony Hoare meant. Also, that essay is criticized a lot for being purely academic and not very practical, so I find it suspicious it's basically the only big source for anyone in SE feeling that null in itself is evil. If you want to argue his point, you'd have to argue that our everyday use of basic cardinalities (especially 'zero or one to any') is evil.
|
|
| Dec 7, 2022 at 15:50 | comment | added | BenMcLean981 | This is something I think TypeScript and Rust do way better than most languages. In Rust you have that Option type built in. You HAVE to handle nulls. In Typescript you have to specify when a value can be null or undefined, then the compiler forces you to handle these cases. Really obvious stuff and I can't believe C# doesn't have it. | |
| Jul 29, 2020 at 16:41 | comment | added | ChiefTwoPencils |
@MattDavey, with regards to Nullable<T> you could say it's the reverse of the concept. They took something that cannot be null and wrapped it in something that can.
|
|
| Jul 13, 2018 at 12:11 | history | edited | HAEM | CC BY-SA 4.0 |
added 127 characters in body
|
| Oct 14, 2017 at 14:05 | comment | added | John Demetriou | @MattDavey The main reason is that in .NET System.Nullable is limited to value types This will change with c# 8 | |
| Apr 4, 2017 at 20:10 | comment | added | Andrew Gray |
Alternate perspective - null is an empty bucket. When I say int? foo = null in C#, I'm saying, "There's a bucket called foo that holds either a whole number, or nothing." We are saying that a particular variable can be empty. This sort of case is where I ally myself with the viewpoint that null is a failure of a type system, rather than 'evil'. While this answer about the nature of null raises good points, it's describing a symptom, not the source problem, which are type systems that sometimes have default values, but sometimes don't. In other words, the language is inconsistent.
|
|
| May 27, 2016 at 20:57 | comment | added | sara |
@Deduplicator there are more issues: null is typeless. Also, Maybe and Either are monads and allow for nice composition of functions with graceful error handling and other higher-order function operations.
|
|
| Apr 10, 2015 at 21:54 | comment | added | Deduplicator | Null being the problem is a very popular standpoint. Trouble is, it's mis-identifying the problem, unescapable nullability: programmers.stackexchange.com/a/253819 The Java enhancement request linked actually shows it well. | |
| Mar 9, 2015 at 18:00 | comment | added | Ky - |
Java 1.8 introduced the Optional type: docs.oracle.com/javase/8/docs/api/java/util/Optional.html
|
|
| Nov 21, 2014 at 18:57 | comment | added | qwerty13579 | The problem isn't NULL, it's that languages don't handle it well. SQL handles NULLs well; any query against a NULL doesn't return that row unless IS NULL is specified (niether SELECT * FROM x WHERE name = 'BOB' and SELECT * FROM x WHERE name <> 'BOB' will return a row with a null name). This works well and doesn't force tons of extra error handling code. myObject.myField should return a NULL if myObject is null, not throw and error; for value types return a certain value (such as zero for numerics). For purists, have an OPTION STRICT NULL to throw exceptions. | |
| Oct 27, 2014 at 23:32 | comment | added | Asad Saeeduddin | @KChaloux I wish you'd write an answer to the question, your comments alone are more informative than this answer. | |
| Aug 26, 2014 at 20:03 | comment | added | Panzercrisis | For the video that you linked to, could you please provide a TL;DR of what he was trying to say? I tried watching that a few months ago, but even after 10 minutes, he keeps on rambling unfortunately. | |
| Aug 26, 2014 at 16:30 | comment | added | Tulains Córdova | Isn't this a link-only answer ? | |
| Aug 7, 2014 at 19:35 | comment | added | KChaloux |
@bigp Ultimately, null exceptions aren't usually exceptional cases. We shove "null" into places where we just don't have a value, and then we have no way of distinguishing whether or not our inputs are going to cause a crash when we try to access them. Using an Option type to model things that may or may not have values, and always assuming non-option types have values, is a much clearer way of distinguishing intent.
|
|
| Aug 7, 2014 at 19:27 | comment | added | KChaloux |
@bigp The point of any type system is to help distinguish and disallow certain kinds of errors as early as possible (at compile time). If your language has an "Option" type, it's free to disallow any non-Option values from being null. There will no longer be any chance of a null exception caused by a function that accepts a String, because the String type cannot hold null. The type Option<String> explicitly tells the type system "This may or may not have a value, and you need to deal with that" at compile time. It's a way to help you catch missing-value errors as early as possible.
|
|
| Aug 7, 2014 at 17:05 | comment | added | chamberlainpi | @KChaloux I realize this answer and it's string of comments is a bit old, but I had to get some clarification. Is the whole "point" of an Option Type to make it easier to distinguish a specific kind of error (a NullString, as opposed to just a generic 'null' exception)? If there's more to it... I think I missed something. | |
| May 3, 2014 at 12:19 | comment | added | Bernhard Barker | Can you put some highlights from the presentation in the answer as to actually answer the question (as opposed to pretty much being a link-only answer)? | |
| Mar 13, 2014 at 20:18 | vote | accept | Tim Goodman | ||
| Mar 13, 2014 at 15:03 | comment | added | KChaloux | @greenoldman Option types lose almost all of their usefulness in dynamic languages, where you can't provide a non-null type guarantee in the type signature of a function. This is probably why the only languages to have really adopted Option types are statically checked languages. | |
| Mar 13, 2014 at 15:01 | comment | added | KChaloux |
@greenoldman The problem with nulls is that anything can be null, and as a developer you have to be extra cautious. A String type isn't really a string. It's a String or Null type. Languages that fully adhere to the idea of option types disallow null values in their type system, giving a guarantee that if you define a type signature that requires a String (or anything else), it must have a value. The Option type is there to give a type-level representation of things that may or may not have a value, so you know where you must explicitly handle those situations.
|
|
| Mar 12, 2014 at 22:42 | history | made wiki | Post Made Community Wiki by sea-rob | ||
| Mar 12, 2014 at 21:50 | comment | added | Justin Morgan | I don't see a difference between representing "nothing" with a special value called "NONE" vs. using a special value called "null". Sure, you can use a design pattern like this to circumvent a language's treatment of nulls, but Hoare was talking about designing the language itself. I don't see how baking "NONE" into a language is different from baking "null" into it. | |
| May 22, 2013 at 21:36 | comment | added | greenoldman | You pointed out Option pattern which clearly throws an exception (so entire "progress" is switching from bad NPE to good UnsupportedOperationException). As now you mention database, you will get error. And it is no surprise, you cannot escape from errors if you start using values (nulls, nones, whatever) out of domain of current computation. | |
| May 22, 2013 at 15:58 | comment | added | Jonas | @greenoldman there is no such thing as "empty option exception". Try inserting NULL values into database columns defined as NOT NULL. | |
| May 22, 2013 at 13:24 | comment | added | greenoldman | Developer can make error anywhere, so instead of null pointer exception you will get empty option exception. How the latter is better than the former? | |
| Jul 14, 2012 at 1:46 | comment | added | marcus | It looks like some authors criticize things and fail to demonstrate the alternative (maybe they suppose it's obvious?). The Option type is great, but if I don't know it yet, a rant saying that null references are the "billion dollar mistake" without mentioning Option will be preaching to the converted. If I recall correctly, the famous "Goto considered harmful" did receive a reply along the lines of "If we sholdn't use GOTO, what are we supposed to use? Fortran's arithmetic IF?" | |
| Jul 13, 2012 at 17:53 | comment | added | Andres F. | +1 For the Option type. After getting familiar with Haskell's Maybe, nulls start looking weird... | |
| Jul 13, 2012 at 17:47 | comment | added | MattDavey | Nullable<x> in C# is a similar concept but falls way short of being an implementation of the option pattern. The main reason is that in .NET System.Nullable is limited to value types. | |
| Nov 14, 2011 at 2:05 | comment | added | Job |
Is option pattern different from Nullable<x> in C# language?
|
|
| Oct 19, 2010 at 17:10 | comment | added | Tim Goodman |
+1 for the Option pattern article. I wasn't familiar with option types before this thread. It seems using option types and pattern matching has some of the same benefits I liked in Note to self's answer.
|
|
| Oct 18, 2010 at 21:11 | history | answered | Jonas | CC BY-SA 2.5 |