Null Pointer Exception

A Java Runtime Exception that signals an attempt to access a field or invoke a method of a null object.

Note that the NullPointerException can often be avoided by the use of NullObjects rather than null for 'not found' situations.

I use NoNullBeyondMethodScope to avoid NullPointerExceptions.

NullConsideredHarmful contains proposals to get rid of NullPointerExceptions.

NullIsBenign contains an alternate proposal to get rid of NullPointerExceptions.

Copied from NullIsBenign:

[...] Why is NullPointerException thrown so often?

I think that's a good, basic question. I am interested in someone who has studied code to see why this happens. There are some reasons I've heard for it that I don't buy, namely: Some folks say "because programmers are stupid and write bad code" - I don't agree with that. Others have said: "because the languages are bad for allowing null in the first place" - but null is a fact of data sets in the real world. My own opinion - based on my own code and so I'd love to see other's experiences - is that the mind assumes a default no behavior. One thinks: if there's nothing there, do nothing... and of course the language wants you to be explicit about that and first check that there is indeed nothing there. Why do you think NPE is thrown so frequently?

OTOH, some people find that NPE is not thrown frequently in their code. Does that mean they are better programmers? ;-)

This often becomes a default route for handling other kinds of errors. For example, look up a word in a dictionary and return NULL if it isn't found. Someone who uses the value without checking for NULL explicitly will get a Null Pointer Exception. Is this better or worse than throwing an ItemNotFoundException? directly from the search routine?

It is better to return null. While the ItemNotFoundException? forces that person's code to prepare for not finding something, it doesn't get the concept right. If a search found nothing, then it found null. If you can't connect to the database to do the search in the first place, then you throw an exception.

A more interesting example (for me) is the dynamic downcast found in (e.g.) Eiffel and C++. This returns NULL if an object is not of the expected subclass. In other words, the static type error-detection mechanism punts, and commutes the type error into a NULL pointer error which is caught by the runtime system. It's a point of trade-off between statically checking and dynamic checking. -- DaveHarris

''Nulls are deadly poison that should NEVER be allowed to leak into an application from low-level code like the lookup example. Why? Becaue null pointer exceptions don't tell you the name of the null variable, at most the line number at which it occurred. By testing for lookup failure in the lookup routine, you can throw a custom exception that says exactly what's going on: Customer name SoAndSo? was not found in {list, of, customer, names}. See http://virtualschool.edu/wap for elaborations on this theme. --BradCox''

Actually "null" means "uninitialized". It means that there is no object associated with an identifier. If a lookup function returns "null" as a result, it may mean that there is no object as a result. In my opinion this reveals its intent. If, say, a login function returns "null" meaning that there is no such a host (instead of HostNotFoundException?) - I think it is not correct, because NullPointerException would mean anything, except the fact of not found host. So, whether to return "null" or not depends on how your code explains what you mean by returning "null" or throwing an exception. --KirillKalishev

the try{}catch(){} thingy is pretty expensive in Java. Exceptions are (IMO) for taking car of exceptional events. Not finding something in a Dictionary isn't really all that exceptional (the odds are 50/50, if probability taught me anything :).

Therefore, specifying that

 Object get( Object key ) throws ItemNotFoundException?

isn't very useful. We already have (or should have) a

 boolean contains( key )

accessor... if we really want to know, why not use it?

--AustinDavid

More precisely, the catch(){} thingy is expensive. If no exception is thrown, there is no direct CPU overhead for the try. So, as AustinDavid (and apparently JamesGosling) opines, exceptions are for exceptional events.

Disclaimer: I believe JVM implementers have sufficient leeway to upset this assessment. --KielHodges

BTW, I don't understand the 50/50 probability of finding something in a Dictionary. Wouldn't the odds depend greatly on what had been put in the Dictionary and what you were looking for? It's easy to conceive of a program that initalizes a Dictionary and then subsequently always gets a hit. Am I missing something? (Yes; it was a joke. I hated Probability. I do have systems that hit 100%, though. -- AustinDavid)

If you expect clients to call contains() before calling get(), then it's reasonable to treat get() on a non-existent key as a rare event.

But in practice I agree; it was a bad example. (That's why I left the question open.) get() and contains() usually involve doing much the same work; I often write:

boolean contains( Object key ) { return get( key ) != null; }

In other circumstances it may be better to (a) treat it as an error, and (b) have the error detect ASAP by throwing an exception. Returning null means the error isn't detected until the result is dereferenced. -- DaveHarris

In PythonProgramingLanguage? (yay for python), accessing a nonexistant dict key will raise (throw) a KeyError?. However, some method or other overrides that, allowing you to add a default value. I am not sure whether this would rely on exceptions internally.

Languages are beginning to support a user-supplied default value. You pass a second argument to the get() which specifies the result to return if the item is not found. This seems like a great solution to me.

A slightly different perspective, building on the above: get() on a nonexistent key isn't necessarily an error, so much as an unexpected/undefined situation. The subsequent blind deref itself is the real error. Either way, IMO I'm better off to write code that doesn't know whether the Dictionary will spew chunks or gleefully toss an exception, so I'll check contains() first (besides, I can always get another 200MHz next week) -- AustinDavid

Huh, maybe I'm being paranoid, but the contains() gains you nothing in a multi-whatevered environment: the get()-contains() sequence isn't atomic. You'd have to synchronize. And that's expensive.

Um, sounds like PrematureOptimization to me.

The more important point is the added complexity (or the possibility of forgetting to synchronize), not that it's expensive.

Though, Austin, don't you already know if the Dictionary will toss an exception by reading the method signatures? Or by not catching an Exception and seeing if the compiler slaps your wrist for it?

Unless it's an UncheckedException.

It seems that this discussion is stuck in an endless loop:

start:

  claim  "Returning null is good, because that is the value meaning 'nothing found', which is not an exception."
  object "But then, there is no guarantee that the caller will check for null. He might assume that the value is
  not null, and get a NullPointerException at some undefined location. It will be hard to trace this bug
  back to its cause."
  claim  "OK, so we should not use null, and throw a checked exceptions instead."
  object "But then we force the caller to catch the exception, even if a null value is acceptable."

goto start

At the heart of the first objection, the problem is that Java does not distinguish between possibly-null values and never-null values. It allows a null value to have any reference type, so that it is never safe to dereference such values.

If I can say: String is a type which does not include null, but ?String can additionally contain null, then the problem is solved. A get on a Map<String,String> has type ?String. You can pass this value around, but the compiler can make sure that you check it is not null before dereferencing it, or storing it in a String variable.

This is something the NiceLanguage extension of Java allows. This point is covered in http://nice.sourceforge.net/safety.html, together with other safety aspects.

DanielBonniot

C# has a nice construct for casting:

instanceOfTypeA = instanceofTypeB as TypeA; if (instanceOfTypeA != null) {...

which nicely avoids the Exception overhead.

JoshuaBloch's book describes a similar pattern. Something like:

 if (!(obj instanceof MyClass)) {...

-- EdPoor

As a wise programmer pointed out to me, it's kind of funny that it's called NullPointerException. Isn't this language not supposed to have pointers? -- ChristianTaubman

It does have pointers, it just calls them references. DotNet, being superior, has a NullReferenceException? :-)

Bunkum - References are not pointers. A C/C++ pointer is an address. Given addresses, you can manipulate memory.

This is an oversimplification. First, let's consider "Standard C" (C89 or C99), or Standard C++. These standards say nothing about whether pointers are addresses, and even if they are, that doesn't allow you to "manipulate memory" as such except by invoking UndefinedBehavior. What pointers do allow is to access the "representation" of a type used by the C/C++ implementation, but since basically the only thing you can do with that according to the language standards is to copy a representation from one "object" (not in the OO sense) to another of the same type -- which you can also do with memcpy -- it's not all that useful.

But some people, quite legitimately, don't care about Standard C -- what if we're talking about, say, C on Windows? In that case, we're relying on a particular set of implementations, or on an operating system ABI, so it's still not correct to say "A C/C++ pointer is an address". At most it is represented as a (virtual) address on a particular platform.

Now, in practice it is difficult to implement C or C++ with pointers represented as anything other than addresses -- partly because it would not conform to most operating system ABIs, and partly because the standards foolishly specify that if the representation of a pointer is mangled and then restored, it still points to the same objects. This is clearly a specification bug: it breaks ConservativeGarbageCollection? and puts other undesirable constraints on implementations. Nevertheless, C and C++ pointers are from a language semantics point of view references, not addresses. The term "pointer" is just a historical accident. Nor is "pointer arithmetic" a defining feature -- some languages, such as CycloneLanguage, allow arithmetic on references that cannot represented as just addresses.

A reference allows you to handle the thing to which it refers, rather being the memory address (or offset) where something is stored. If you implement Java references as "handles" (pointers to pointers to where the object state is stored) you can rearrange memory to create bigger contiguous free spaces. If you were a cynic writing an inferior JVM for a browser you could just implement references directly as pointers - meaning that your implementation will be faster, but it will become increasingly difficult to find contiguous free spaces over time. Your JVM will have difficulty with server-side apps, but if you only care about applets that won't matter. Like so many other names it is misleading: "Atom" (Greek, "that which cannot be divided"?), "The Independent" (it isn't), "The German Democratic Republic" (I doubt it), "The BusinessObjectNotation" (it isn't a notation).

This is a common mistake among those people who learned about pointers from C and C++. Addresses and pointers are not the same. A pointer is a language level concept: an indirect reference to a dynamically allocated, typed value. An address is a machine level concept: an index into the address space of the process that references a byte or word of untyped data. In most languages descended from Algol, such as Modula-2, Ada, etc. pointers and addresses are two completely distinct concepts, and addresses are represented by a distinct type (e.g. ADDRESS). A program cannot perform arithmetic on pointers but can on addresses. One must explicitly call intrinisic functions to get the address of a variable or convert a pointer to an address. Thus potentially dangerous logic, that works around the type system, is highlighted within the code.

Similarly, C has separate types for pointers and addresses: T* points to a value of type T, void* points to some raw memory. However, C confuses the issue by overloading what pointers are used for and by silently converting between pointers and addresses.

C allows programs to acquire pointers to auto and global variables, which can cause dangling pointer problems when auto variables go out of scope. Other Algol descendents use PassByReference parameters instead.
C uses the same type to point to an array of objects and a single object, and also allows pointer arithmetic so that pointers can also be used as array iterators. C silently converts between an array value and a pointer to the array's first element. Other Algol descendents provide intrinsic functions and control structures for iterating over arrays, and automatically optimise whether passing an array to a function actually copies the array or passes the address of the array on the stack.
C implicitly converts typed pointers to untyped addresses (void*), and even worse, implicitly converts untyped addresses to typed pointers, with no need for explicit casts. Other Algol descendents require explicit conversions between addresses and pointers. C++ only requires explicit casts from void*.
C doesn't allow you to perform address arithmetic on void* values (note: you can in gcc, but that's an extension); you first have to cast a void* to a typed pointer.

So, Java object references are pointers in the commonly understood meaning of the term. [And pointers are also references; these terms are effectively synonyms.] They are not C-style pointers-that-are-also-addresses-or-arrays-or-array-iterators-depending-on-how-you-use-them.

C++ further confuses the issue by using the term "reference" for something else -- basically a pointer-that-gets-implicitly-dereferenced-in-some-contexts-and-changes-the-argument-passing-convention.

Dynamically allocated? Then what's the politically correct term for an indirect reference to a typed value on the stack?

Languages with PassByReference don't need indirect references to typed values on the stack. C++ allows "references" to values on the stack, which are just name aliases and don't exist at runtime unless passed to a function or stored in an object. Java doesn't provide any way of obtaining indirect references to stack data.

Sorry, that answer didn't help. What I had in mind is

int a = 7 ;
int *b = new int ;
int *c = &a ;

void foo ( int * d ) ;

foo(b) ;
foo(c) ;

b is a pointer. What's c? not a pointer, because a wasn't allocated dynamically. What's d? we've no idea whether the value on the other side of the indirect reference was dynamically allocated or not.

That is C++ code, so the type of c is a pointer-that-is-also-an-address-or-array-or-array-iterator-depending-on-how-you-use-it. Above it is being used to implement PassByReference because C++ doesn't allow functions to have PassByReference(*) parameters. Well, I assume so, but there is no way of knowing from C++'s type system exactly what the function foo will do with its d argument. As long as foo actually uses the argument d as a PassByReference parameter the program works fine. If it stores the pointer longer than the lifetime of the call, it's a bug.

This is one of the flaws with C++'s pointers-that-are-also-addresses-or-arrays-or-array-iterators-depending-on-how-you-use-them. It is why most other Algol-derived languages make explicit the distinction between pointers and addresses and support PassByReference procedure parameters. And it is also why people who have only learnt languages based on C get confused by the fact that Java object references are what are commonly known as pointers.

(*) I should have added "or-reference" to that newly coined term, but I didn't want it to become too long and unwieldy!

A null pointer exception in a public method always indicates a bug in the code that throws it, except in the case where a called method returns a null and the documentation does not mention that it might. Your method should never throw npe, it should be throwing IllegalArgumentException or IllegalStateException. -- PaulMCanberra

Careful about throwing around "always" and "never", they cry out for proof, whereas "almost always" doesn't carry the same burden.

Why does NullPointerException exist? See NullIsBenign

See: NullIsaHack

One of the common cause of NullPointerException is using equals() method with unknown object while comparing with String literal like object.equals("Java"). This code will throw NPE if object is null which can be safely avoided by writing same code as "Java".equals(object). This code will return false instead of throwing NPE.

CategoryException | CategoryJava | CategoryNull