Tag Info

Hot answers tagged

169

Boss-speak is always tough... Zero is a number so you can do things with it. Null is a unicorn. It doesn't exist so you can't do anything at all with it.


94

To explain to a boss the difference between "zero" and "null": "Zero" is a value. It is the unique, known quantity of zero, which is meaningful in arithmetic and other math. "Null" is a non-value. It is a "placeholder" for a data value that is not known or not specified. It is only meaningful in this context; mathematical operations cannot be performed on ...


63

Disclaimer: Since I don't know any language designers personally, any answer I give you will be speculative. From Tony Hoare himself: I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object oriented language (ALGOL W). My goal ...


58

The question is not so much whether you should check for null or let the runtime throw an exception; it is how you should respond to such an unexpected situation. Your options, then, are: Throw a generic exception (NullReferenceException) and let it bubble up; if you don't do the null check yourself, this is what happens automatically. Throw a custom ...


53

I'm sure designers of languages like Java or C# knew issues related to existence of null references Of course. Also implementing an option type isn't really much more complex than null references. I beg to differ! The design considerations that went into nullable value types in C# 2 were complex, controversial and difficult. They took the design ...


48

I would say that NULL is the correct choice for "no email address". There are many "invalid" email addresses, and "" (empty string) is just one. For example "foo" is not a valid email address, "a@b@c" is not valid and so on. So just because "" is not a valid email address is no reason to use it as the "no email address" value. I think you're right in saying ...


41

That quote points to a problem that occurs if the declaration and assignment of identifiers (here: instance members) are separate from each other. As a quick pseudocode sketch: class Broken { val foo: Foo // where Foo and Bar are non-nullable reference types val bar: Bar Broken() { foo = new Foo() throw new Exception() ...


39

IMHO trying to handle null values that you don't expect leads to overly complicated code. If you don't expect null, make it clear by throwing ArgumentNullException. I get really frustrated when people check if the value is null and then try to write some code that doesn't make any sense. The same applies to using SingleOrDefault (or even worse getting ...


38

Is there anything inherently wrong with just storing false as null? Yes. If so can you please explain what the down side should be? NULL is not the same as False. By definition, comparisons (and logic) that involve NULL should return values of NULL (not False). However, SQL implementations can vary. True and NULL is NULL (not False). True ...


36

Just rephrase the equations into sentences: "What is the percentage change if you start with an unknown value and you end up with 150?" and "What is the percentage change if you start with 85 and you end up with some unknown value?" Of course, the answer to both is "It can't be calculated, because one of the critical pieces of the calculation ...


36

In your example myApple has the special value null (typically all zero bits), and so is referencing nothing. The object that it originally referred to is now lost on the heap. There is no way to retrieve its location. This is known as a memory leak on systems without garbage collection. If you originally set 1000 references to null, then you have space for ...


28

If null is a reasonable input parameter for your method, fix the method. If not, fix the caller. "Reasonable" is a flexible term, so I propose the following test: How should the method hande a null input? If you find more than one possible answer, then null is not a reasonable input.


27

The returning of null makes sense to me since manipulating a null string should result in a null string, not an error Well, that is your opinion. Others may argument that String operations on a null object, which does not contain a String, make no sense and hence should throw an Exception Why "Java designers" did or did not something is difficult to ...


25

I've been trained to believe that throwing the ArgumentNullException is "correct" but an "Object reference not set to an instance of an object" error means I have a bug. Why? Suppose I call method M(x) that you wrote. I pass null. I get an ArgumentNullException with the name set to "x". That exception unambiguously means that I have a bug; I should not ...


24

Null references aren't "shunned" any more so than exceptions, at least by anyone I've ever known or read. I think you're misunderstanding the conventional wisdom. What's bad is an attempt to access a null reference (or dereference a null pointer, etc.). This is bad because it always indicates a bug; you would never do something like this on purpose, and ...


23

Consider: Language, Framework, Context. 1. Language Using ∞ can be a solution for a maximum. JavaScript, for example, has an infinity. C# doesn't¹. Ada, for example, has ranges. C# doesn't. In C#, there is int.MaxValue, but you cannot use it in your case. int.MaxValue is the maximum integer, 2,147,483,647. If in your code, you have a maximum value ...


23

Null serves a very valid purpose of representing a lack of value. I will say I'm the most vocal person I know about the abuses of null and all the headaches and suffering they can cause especially when used liberally. My personal stance is people may use nulls only when they can justify it's necessary and appropriate. Example justifying nulls: Date of ...


21

While agreeing with the above comments, I would add this argument as a primary motivation: It is obvious to any programmer looking at a database that a field marked NULL is an Optional field. (i.e. the record doesn't require data for that column) If you mark a field NOT NULL, any programmer should intuitively assume that it is a Required field. In a field ...


21

I suppose if you are immediately dereferencing the variable, you could debate either way, but I would still prefer the ArgumentNullException. It is much more explicit about what is going on. The exception contains the name of the variable that was null, whereas a NullReferenceException does not. Particularly at the API level, an ArgumentNullException makes ...


19

Exceptions should only be thrown when there is an error and asking for a thing is not an error. Asking for a thing may not be an error, but not having permissions to something you asked for is surely some sort of error. Exceptions are an alternative way of reporting exceptional conditions, to be used instead of special return values (such as null, ...


19

The NullReferenceException basically tells you: you are doing it wrong. Nothing more, nothing less. It's not a full-fledged debugging tool, on the contrary. In this case I'd say you're doing it wrong both because there is a NullReferenceException you didn't prevent it in a way you know why/where it happened and also maybe: a method requiring 20 objects ...


19

When talking to you boss, just use 0 for zero, and ? for null. It correctly captures that it's a placeholder for something but that you don't know what it is.


17

The habit of checking for null to my experience comes from former C or C++ developers, in those languages you have a good chance of hiding a severe error when not checking for NULL. As you know, in Java or C# things are different, using a null ref without checking for null will cause an exception, thus the error will not be secretly hidden as long as you ...


17

What you have there is perfect. It's clear and simple. If you had several cases testing for null, I'd combine them. This is bad as it tests for (metadata != null) repeatedly. if ((metadata != null) && (metadata.TypeEnum != CellTypeEnum.Status)) { ... } else if ((metadata != null) && (metadata.TypeEnum != CellTypeEnum.Info)) { ... } else ...


15

Actually, null is a great idea. Given a pointer, we want to designate that this pointer does not reference a valid value. So we take one memory location, declare it invalid, and stick to that convention (a convention sometimes enforced with segfaults). Now whenever I have a pointer I can check if it contains Nothing (ptr == null) or Some(value) (ptr != null, ...


14

I believe it is primarily historical baggage. The most prominent and oldest language with null is C and C++. But here, null does makes sense. Pointers are still quite numerical and low-level concept. And how someone else said, in the mindset of C and C++ programmers, having to explicitly tell that pointer can be null doesn't make sense. Second in line ...


13

How about this: 0 is the answer to "how much liquid is there in an empty bottle?". NULL is the answer to "what is the content of an empty bottle?". Or if you imagine a childless man: the number of his children is 0 his oldest child is NULL The basic difference is that 0 is about measurable quantity, while NULL is about existence. Being a quantity, ...


13

The same ways you guarantee any other data is in a valid state. One can structure semantics and control flow such that you can't have a variable/field of some type without fully creating a value for it. Instead of creating an object and letting a constructor assign "initial" values to its fields, you can only create an object by specifying values for all ...


12

By allowing nulls in a boolean field, you are turning an intended binary representation (true/false) into a tri-state representation (true, false, null) where your 'null' entries are indeterminate. The 'null' value is neither appropriately 'true' nor 'false.' What reason would you have to augment your representation to be inaccurate? Even if you decide on ...


12

Use asserts to test and indicate pre/postconditions and invariants for your code. It makes it so much easier to understand what the code expects and what it can be expected to handle. An assert, IMO, is a suitable check because it is: efficient (usually not used in release) , brief (usually a single line) and clear (precondition violated, this is a ...



Only top voted, non community-wiki answers of a minimum length are eligible