Re: NullPointerException
According to Roedy Green <see_website@mindprod.com.invalid>:
On Thu, 25 Feb 2010 00:09:22 -0800 (PST), Jack <junw2000@gmail.com>
wrote, quoted or indirectly quoted someone who said :
Does java NullPointerException always cause crash?
it never causes a crash.
Theoretically you are right. However I did encounter JVM implementations
which occasionally had trouble with NullPointerException (including a
port of Sun's JVM for FreeBSD).
To be precise, in many JVM, null references are not checked before
access; instead, the access is trapped by the OS, which generates a
system-level exception (on Unix-like systems, a SIGSEGV or SIGBUS
signal). The JVM intercepts that signal, obtains the faulty code
address, and converts the signal into a NullPointerException which is
then thrown in the offending thread.
Interception of the signal, obtention of the faulty code address, and
reconstruction of the offending opcode address and stack trace are very
system-dependent. This depends on an awful lot of ill-defined details
(such as how the OS decides where allocated blocks will be in the
address space) which may change between OS versions. The main result is
that conversion of null pointer accesses into NullPointerException is
somewhat less robust than the rest of the JVM, especially in
non-mainstream platforms. It is not the NullPointerException which
crashes the JVM, but the JVM failure to throw a NullPointerException
which implies the crash.
Of course, a JVM which fails to convert a null pointer access into
a NullPointerException is not a compliant implementation of the Java
Virtual Machine. Nevertheless, such implementations exist, so, in the
interest of portability, it is best to endeavour not to access null
pointer references needlessly. A rather common idiom (in Sun's own
source code, no less) is to test arguments explicitly. For instance,
taken from java.io.Writer source:
protected Writer(Object lock) {
if (lock == null) {
throw new NullPointerException();
}
this.lock = lock;
}
Here, the purpose of the explicit test is to have an early NPE (so that
it is thrown when this constructor is used, and not later on, when
"lock" is used) but it also avoids the kind of bug I was explaining
above.
At my job, we tend to handle null pointer accesses as bugs, just like
out-of-bounds array accesses: they are not meant to happen, never. In
our public API, we add such explicit tests, so that offending callers
are duly detected as soon as possible.
--Thomas Pornin